I can not figure out, where the uart, baudrate is changed in the linux kernel.
I am using the adi_uart4.c driver (not in the major 4.14 kernel yet). But it is designed like all the other in driver/tty/serial/
While booting:
CONFIG_BAUDRATE 115200 -> uboot baudrate
earlyprintk=serial,uart0,115200 -> cmdline arg in uboot
console=ttySC0,115200 -> cmdline arg in uboot
??? -> set to 56700
Linux boot output stops, because of baudrate change:
[..]
Freeing unused kernel memory: 1024K
Starting logging: OK
Starting mdev...
Starting watchdog...
Initializing random number generator... done.
Starting network...
/bin/sh: run-parts: not found
Starting inetd: OK
��怘�~3f<��<����f<���3�f��Æ�����`?怘���<f?����`<?����`?<��~<�����������
Thank you #sawdust.
There was an additional userspace change in /etc/inittab
# Put a getty on the serial port
ttySC0::respawn:/sbin/getty -L ttySC0 56700 vt100 # GENERIC_SERIAL
Related
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 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 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.
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.