I have problem booting Linux 3.16.1. I have compiled sources from http://www.kernel.org with at91sam9263_defconfig.
I have added Flattened Device Tree support in Boot options.
Followin tips suggested in this (https://www.slideshare.net/softpapa/device-tree-support-on-arm-linux-8930303) presentation to turn on Support device tree in /proc but i don't have that option in menuconfig.
I have U-Boot bootloader version 2014.10rc2 which supports device tree.
I have generated dtb from script shipped with kernel:
make at91sam9263ek.dtb
And now i'm getting this error:
Welcome to minicom 2.5
OPTIONS: I18n
Compiled on Feb 9 2011, 14:45:00.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
RomBOOT
>
U-Boot 2014.10-rc2-00200-g9170818-dirty (Sep 23 2014 - 15:16:39)
CPU: AT91SAM9263
Crystal frequency: 16.368 MHz
CPU clock : 199.919 MHz
Master clock : 99.960 MHz
DRAM: 64 MiB
WARNING: Caches not enabled
NAND: 256 MiB
MMC: mci: 0
In: serial
Out: serial
Err: serial
Net: macb0
Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.
Hit any key to stop autoboot: 0
U-Boot> tftp uImage
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.1.247; our IP address is 192.168.1.240
Filename 'uImage'.
Load address: 0x22000000
Loading: #################################################################
#################################################################
#################################################################
##############
1.2 MiB/s
done
Bytes transferred = 3068016 (2ed070 hex)
U-Boot> tftp 20000000 dt
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 192.168.1.247; our IP address is 192.168.1.240
Filename 'dt'.
Load address: 0x20000000
Loading: #
340.8 KiB/s
done
Bytes transferred = 13279 (33df hex)
U-Boot> bootm 22000000 - 20000000
## Booting kernel from Legacy Image at 22000000 ...
Image Name: Linux-3.16.1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3067952 Bytes = 2.9 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 20000000
Booting using the fdt blob at 0x20000000
Loading Kernel Image ... OK
Loading Device Tree to 23ea3000, end 23ea93de ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Error: unrecognized/unsupported device tree compatible list:
[ 'atmel,at91sam9263ek' 'atmel,at91sam9263' 'atmel,at91sam9' ]
Available machine support:
ID (hex) NAME
000004b2 Atmel AT91SAM9263-EK
Please check your kernel config and/or bootloader.
Solution:
Add this line to .config:
CONFIG_MACH_AT91SAM9_DT=y
The correct configuration for this board when using device tree is at91_dt_defconfig.
However, I am quite surprised to see someone trying to use such an old kernel. This board is fully supported upstream. Why don't you use v5.3? If this doesn't work, please report any bug, we will be happy to help correct them.
Related
I'm trying to upgrade my u-boot from 2009 to 2020 using buildroot, but when I build the new one it doesn't boot (and I don't have JTAG).
When I load it with imx_usb_loader it works but when I flash it on the Nand, it doesn't boot on it.
As u-boot files, I use mx6sabreauto.c, mx6solo.cfg and mx6sabreauto.h
I don't use SPL or DTS, I only generate u-boot.imx
Boot logs with imx_usb_loader :
U-Boot 2020.04 (Feb 11 2023 - 15:41:38 +0100)
CPU: i.MX6SOLO rev1.3 at 792MHz
CPU: Industrial temperature grade (-40C to 105C) at 50C
Reset cause: POR
Model: i.MX6 DualLite/Solo SABRE Automotive Board
Board: MX6Q-Sabreauto rev#
DRAM: 2 GiB
NAND: nand_base: device found, Manufacturer ID: 0x2c, Chip ID: 0xd3
nand_base: Micron NAND 1GiB 3,3V 8-bit
nand_base: Micron NAND 1GiB 3,3V 8-bit
nand_base: 1024 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 128
use legacy bch geometry
1024 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... MMC: no card present
mmc_init: -123, time 2
Warning - No block device, using default environment
Loading Environment from NAND... Scanning device for bad blocks
Warning - bad CRC, using default environment
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
Net: FEC [PRIME]
Warning: FEC (eth0) using random MAC address - ea:37:e5:51:c1:86
Boot from USB for mfgtools
Warning - Use default environment for
using default environment
Hit any key to stop autoboot: 0
Flash logs :
=> nand erase 0x0 0x40000000
NAND erase: device 0 whole chip
Erasing at 0x3ffc0000 -- 100% complete.
OK
=> tftp 0x10800000 u-boot.imx
Using FEC device
TFTP from server 192.168.30.30; our IP address is 192.168.30.10
Filename 'u-boot.imx'.
Load address: 0x10800000
Loading: #####################################################
3.9 MiB/s
done
Bytes transferred = 777216 (bdc00 hex)
=> nand read 0x10800000 0x00000000 777216
NAND read: device 0 offset 0x0, size 0x777216
7827990 bytes read: OK
=> reset
resetting ...
It worked when I flashed from the Linux rootfs using these commands :
$ flash_erase /dev/mtd0 0 0
$ kobs-ng init -x u-boot.imx --search_exponent=1 -v
It seems that the "search-exponent" option did the trick.
I create a linux booting image using TI SDK (am335x) and booting Beaglebone black.
and u-boot boot message is..
U-Boot SPL 2019.01-gf95c3e0297-dirty (Oct 15 2019 - 08:45:45 +0900)
Trying to boot from MMC1
U-Boot 2019.01-gf95c3e0297-dirty (Oct 15 2019 - 08:45:45 +0900)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment
<ethaddr> not set. Validating first E-fuse MAC
Net: eth0: ethernet#4a100000
Warning: usb_ether MAC addresses don't match:
Address in ROM is de:ad:be:ef:00:01
Address in environment is f4:e1:1e:ce:d7:49
, eth1: usb_ether
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
4080128 bytes read in 266 ms (14.6 MiB/s)
36717 bytes read in 3 ms (11.7 MiB/s)
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8fff4000, end 8fffff6c ... OK
Starting kernel ...
and i can't decide three warning message need to solved.
Loading Environment from FAT... *** Warning - bad CRC, using default environment ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt **
u-boot and linux kernel work properly.
Do I need solve this warning ?.
Maybe your u-boot script didn't switch to the right partition of MMC before started reading uEnv.txt or so. This is okay if you are fine with booting behavior. These files contain things like do you want to enable HDMI, or console, etc. But the same could be done directly in u-boot env.
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 try to understand the build and booting process of Linux kernel for ARM. I took vanila linux from www.kernel.org and build it after run configuration for AT91SAM9260.
In message when we compile the kernel showed that:
==========================================
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.9.1+
Created: Sat Nov 23 18:15:58 2013
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1635544 Bytes = 1597.21 kB = 1.56 MB
Load Address: 20008000
Entry Point: 20008000
Image arch/arm/boot/uImage is ready
==========================================
My questions are:
Image type is uncompressed, this means that we don't compress vmlinux to zImage ?
Load Address: 20008000: this is address of decompressed image = ZRELADDR defined in arch/arm/boot/Makefile ?
This address also is address of ../arm/kernel/head.o ?
It seems that we don't use address KERNEL_PHYS , this method is common way or just for AT91SAM family ?
Basically, our procedures to build and booting are:
a. building kernel steps: vmlinux -> uImage (skip to create zImage).
b. kernel booting steps: DataFlash/NAND --load-->uImage (# 0x22200000) ---decompress--> uncompressed image (# 0x20008000).
In this case, no zImage in booting process although in build message I saw zImage created. I'm wrong ?
4 . How about the address 0xC0008000 which I found in /arch/arm/kernel/vmlinux.lds at line:
. = 0xC0000000 + 0x00008000;
Do we use it ?. I confuse this address with the ZRELADDR.
Regards.
The uImage file has most probably been built using the zImage. It says uncompressed because the uImage itself is not compressed.
The load address can be used by the boot-loader to store data necessary for the early phases of the Linux kernel boot (such as the command line defined in the bootloader.)
You're right about the boot process. But when the zImage is used then the decompression is done by the kernel instead of the bootloader. See decompress_kernel()
The address 0xc0008000 is a virtual address. It maps to the physical address 0x20008000. Virtual addresses can be used only after Linux sets up the memory translation (MMU).
I would like to know how to set the correct MACH_TYPE or arch_id for the kernel. I searched and found at least 2 references where the kernel would hang at "Starting Kernel ... ". These came with the same answer. Correctly set your Machine Type. But then neither mentions how to do so. Anyone know how to do this?
Pretty good explanation for the hang. and Another good description.
Both of these are close to what I am experiencing when I try to boot my kernel. It gets stuck on "Starting Kernel..." and won't continue. I have built the kernel several times from .configs that were supposed to be exactly for my model.
Timesys (LinuxLink) provides a .config that is supposed to match the kernel that they provide with their free build service. But that doesn't work either. If I use their pre-built kernel it boots up no problem. So I know it is not my u-boot or how I have configured my SD-card. The problem must come from the kernel build.
I run my make like: make ARCH=arm CROSS_COMPILE=${PATH_TO_TOOLCHAIN}/bin/armv7l-timesys-linux-gnueabi- uImage and make my image as follows: sudo mkimage -A arm -O linux -T kernel -C none -a 0x70800000 -e 0x70800000 -n "Linux-2.6.35-ts-armv7l" -d arch/arm/boot/uImage ../../uImage
I am working with a Freescale i.MX53 Eval Board. When I try to run the kernel:
U-Boot 2009.08-dirty (Aug 02 2013 - 19:57:03)
CPU: Freescale i.MX53 family 2.1V at 800 MHz
mx53 pll1: 800MHz
mx53 pll2: 400MHz
mx53 pll3: 432MHz
mx53 pll4: 455MHz
ipg clock : 66666666Hz
ipg per clock : 33333333Hz
uart clock : 66666666Hz
cspi clock : 108000000Hz
ahb clock : 133333333Hz
axi_a clock : 400000000Hz
axi_b clock : 200000000Hz
emi_slow clock: 133333333Hz
ddr clock : 400000000Hz
esdhc1 clock : 80000000Hz
esdhc2 clock : 80000000Hz
esdhc3 clock : 80000000Hz
esdhc4 clock : 80000000Hz
nfc clock : 26666666Hz
Board: MX53-LOCO 1.0 Rev. B
Boot Reason: [POR]
Boot Device: SD
I2C: ready
DRAM: 1 GB
MMC: FSL_ESDHC: 0,FSL_ESDHC: 1
In: serial
Out: serial
Err: serial
Serial reinitilized!
Net: got MAC address from IIM: 00:04:9f:01:f7:ce
FEC0 [PRIME]
Hit any key to stop autoboot: 0
mmc0 is current device
MMC read: dev # 0, block # 2048, count 8192 ... 8192 blocks read: OK
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.35-ts-armv7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2999932 Bytes = 2.9 MB
Load Address: 70800000
Entry Point: 70800000
Verifying Checksum ... OK
XIP Kernel Image ... OK
OK
Starting kernel ...
u-boot env:
bootdelay=3
baudrate=115200
netdev=eth0
ethprime=FEC0
uboot=u-boot.bin
kernel=uImage
nfsroot=/opt/eldk/arm
bootargs_base=setenv bootargs console=ttymxc0,115200
bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${kernel}; bootm
bootcmd=run bootcmd_mmc
ethact=FEC0
lcd=video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary
bootargs_mmc=setenv bootargs ${bootargs} gpu_nommu ${lcd} ip=dhcp root=/dev/mmcblk0p1 rootwait rw
bootargs=console=ttymxc0,115200 gpu_nommu video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary ip=dhcp root=/dev/mmcblk0p1 rootwait rw
bootcmd_mmc=run bootargs_base bootargs_mmc; mmc dev 0; mmc read ${loadaddr} 0x800 0x2000; bootm
loadaddr=0x70800000
stdin=serial
stdout=serial
stderr=serial
The issue is that a double u-boot header has been applied to the image. As per unixsmurf.