Testing Linux kernel image in Qemu - linux-kernel

i'm new to embedded linux field. i am trying to emulate arm develpmnt board using Qemu and boot linux on to it. i compiled the kernel and got the uImage.but when i test this image on qemu it shows--
qemu: fatal: Trying to execute code outside RAM or ROM at 0x50008000
R00=00000000 R01=00000183 R02=00000100 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=50008000
PSR=400001d3 -Z-- A svc32
Aborted.
i used this command for testing
qemu-system-arm -M versatilepb -m 128M -kernel /root/ls6410/kernel/s3c-linux-2.6.28.6-Real6410/arch/arm/boot/uImage.
can anyone suggest an method to fix this?
thanks,

Related

adding RT PRMEEPT_rt patch in imx6ullevk and building yocto rootfs using core-image-rt-sdk in yocto toaster

im using imx6ull , where i need to enable prmeept_rt patch, i have enabled
--->General setup
-->(X) Fully Preemptible Kernel (Real-Time)
in Linux kernel 5.4.3 by using patch-5.4.3-rt1.patch.xz and created kernel image and i tried to boot the board with rootfs build (poky branch is kirkstone) using core-image-minimal image recipe it was not providing me root access ,
So i tried to build another rootfs (poky branch is kirkstone) using core-image-rt-sdk image recipe in yocto toaster it is showing error. as
Nothing PROVIDES 'core-image-rt-sdk'
core-image-rt-sdk was skiped : Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it
how to build rootfs using core-image-rt-sdk image recipe .
any suggestions will be more help full

Why Xorg server fails on system created with Buildroot for Raspberry Pi4?

I am trying to create my own system for Raspberry Pi4 using Buildroot.
Target is to make custom OS with Xorg, Qt5 and OpenGLESv2 HW rendering. I create my custom Buildroot configuration, nothing specific yet. Very similar to default raspberry pi4 buildroot config but enabled Xorg/Mesa/OpenGLES. My config is that:
BR2_arm=y
BR2_cortex_a72=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_CCACHE=y
BR2_CCACHE_DIR="$(BR2_EXTERNAL_I_TREE_PATH)/../.buildroot-ccache"
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_HOSTNAME="MyHost"
BR2_TARGET_GENERIC_ISSUE="Welcome to MyHost"
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_TARGET_GENERIC_ROOT_PASSWD="4rt56gbd"
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_USERS_TABLES="$(BR2_EXTERNAL_I_TREE_PATH)/board/rpi4/users.txt"
BR2_ROOTFS_OVERLAY="$(BR2_EXTERNAL_I_TREE_PATH)/rootfs_overlay/"
BR2_ROOTFS_POST_BUILD_SCRIPT="$(BR2_EXTERNAL_I_TREE_PATH)/board/rpi4/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL_I_TREE_PATH)/board/rpi4/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,967d45b29ca2902f031b867809d72e3b3d623e7a)/linux-967d45b29ca2902f031b867809d72e3b3d623e7a.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2711"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2711-rpi-4-b"
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_PACKAGE_GLMARK2=y
BR2_PACKAGE_MESA3D_DEMOS=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_KMSRO=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_V3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_XCB_UTIL_CURSOR=y
BR2_PACKAGE_XCB_UTIL_KEYSYMS=y
BR2_PACKAGE_XCB_UTIL_WM=y
BR2_PACKAGE_XLIB_LIBFS=y
BR2_PACKAGE_XLIB_LIBXSCRNSAVER=y
BR2_PACKAGE_XLIB_LIBXCOMPOSITE=y
BR2_PACKAGE_XLIB_LIBXFONT=y
BR2_PACKAGE_XLIB_LIBXTST=y
BR2_PACKAGE_XLIB_LIBXVMC=y
BR2_PACKAGE_XLIB_LIBXXF86DGA=y
BR2_PACKAGE_XLIB_LIBDMX=y
BR2_PACKAGE_XAPP_X11PERF=y
BR2_PACKAGE_XAPP_XCALC=y
BR2_PACKAGE_XAPP_XCLOCK=y
BR2_PACKAGE_XDRIVER_XF86_INPUT_KEYBOARD=y
BR2_PACKAGE_XDRIVER_XF86_INPUT_LIBINPUT=y
BR2_PACKAGE_XDRIVER_XF86_INPUT_MOUSE=y
BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBDEV=y
BR2_PACKAGE_XDRIVER_XF86_VIDEO_FBTURBO=y
BR2_PACKAGE_XFONT_FONT_ADOBE_100DPI=y
BR2_PACKAGE_XFONT_FONT_ADOBE_75DPI=y
BR2_PACKAGE_XFONT_FONT_ADOBE_UTOPIA_100DPI=y
BR2_PACKAGE_XFONT_FONT_ADOBE_UTOPIA_75DPI=y
BR2_PACKAGE_XFONT_FONT_ADOBE_UTOPIA_TYPE1=y
BR2_PACKAGE_XFONT_FONT_ARABIC_MISC=y
BR2_PACKAGE_XFONT_FONT_BH_100DPI=y
BR2_PACKAGE_XFONT_FONT_BH_75DPI=y
BR2_PACKAGE_XFONT_FONT_BH_LUCIDATYPEWRITER_100DPI=y
BR2_PACKAGE_XFONT_FONT_BH_LUCIDATYPEWRITER_75DPI=y
BR2_PACKAGE_XFONT_FONT_BH_TTF=y
BR2_PACKAGE_XFONT_FONT_BH_TYPE1=y
BR2_PACKAGE_XFONT_FONT_BITSTREAM_100DPI=y
BR2_PACKAGE_XFONT_FONT_BITSTREAM_75DPI=y
BR2_PACKAGE_XFONT_FONT_BITSTREAM_TYPE1=y
BR2_PACKAGE_XFONT_FONT_CRONYX_CYRILLIC=y
BR2_PACKAGE_XFONT_FONT_DAEWOO_MISC=y
BR2_PACKAGE_XFONT_FONT_DEC_MISC=y
BR2_PACKAGE_XFONT_FONT_IBM_TYPE1=y
BR2_PACKAGE_XFONT_FONT_ISAS_MISC=y
BR2_PACKAGE_XFONT_FONT_JIS_MISC=y
BR2_PACKAGE_XFONT_FONT_MICRO_MISC=y
BR2_PACKAGE_XFONT_FONT_MISC_CYRILLIC=y
BR2_PACKAGE_XFONT_FONT_MISC_ETHIOPIC=y
BR2_PACKAGE_XFONT_FONT_MISC_MELTHO=y
BR2_PACKAGE_XFONT_FONT_MUTT_MISC=y
BR2_PACKAGE_XFONT_FONT_SCHUMACHER_MISC=y
BR2_PACKAGE_XFONT_FONT_SCREEN_CYRILLIC=y
BR2_PACKAGE_XFONT_FONT_SONY_MISC=y
BR2_PACKAGE_XFONT_FONT_SUN_MISC=y
BR2_PACKAGE_XFONT_FONT_WINITZKI_CYRILLIC=y
BR2_PACKAGE_XFONT_FONT_XFREE86_TYPE1=y
BR2_PACKAGE_XDATA_XCURSOR_THEMES=y
BR2_PACKAGE_NODM=y
BR2_PACKAGE_XTERM=y
BR2_PACKAGE_OPENBOX=y
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI4=y
BR2_PACKAGE_RPI_FIRMWARE_X=y
BR2_PACKAGE_PYTHON3=y
BR2_PACKAGE_LIBDRI2=y
BR2_PACKAGE_OPENSSH=y
BR2_PACKAGE_SUDO=y
BR2_PACKAGE_S6=y
BR2_PACKAGE_S6_LINUX_UTILS=y
BR2_PACKAGE_S6_PORTABLE_UTILS=y
BR2_PACKAGE_UTIL_LINUX_BINARIES=y
BR2_PACKAGE_UTIL_LINUX_KILL=y
BR2_PACKAGE_UTIL_LINUX_MOUNT=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="512M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y
First issue comes with X server.
It starts working but very strange/ubnormal. Xorg logs show me lines:
(II) xfree86: Adding drm device (/dev/dri/card1)
(II) xfree86: Adding drm device (/dev/dri/card0)
(II) no primary bus or device found falling back to sys/devices/platform/gpu/drm/card1
But on normal Raspbian OS X server first adds card0 then card1. And makes fall back to card0. Why my Xorg starts with card1?
I think this is my main issue, because of that later GLX extension does not start. And so I cannot make OpenGLES working in my system.
In my config.txt i have line
dtoverlay=vc4-fkms-v3d
and I belive vc4 drivers start properly because I see /dev/dri/card0 /dev/dri/card1 and /dev/dri/renderD128 devices
Maybe someone had similar experience?
What I am doing wrong?
My fault in question.
I was wrong that issue was in order of /dev/dri/card? adding by Xorg.
Issue was different. xserver built in buildroot needs libglamor enabled? this should be enabled in buildroot config. If enabled then es2_info reports no issue with OpenGLES.. besides that in my case still glmark2-es2 does not work with error "Failed to open bo 1: Permission denied"

Uncompressing is not happening with zImage while booting up with u-boot

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 .

xen installation on cent os 6.3

I followed tutorial http://www.howtoforge.com/virtualization-with-xen-on-centos-6.2-x86_64-paravirtualization-and-hardware-virtualization
To install xen on Centos 6.3 everything is going perfect but, after editing /boot/grub/menu.lst
Quote:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_xen-LogVol01
# initrd /initrd-[generic-]version.img
#boot=/dev/sdb
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32.57-2.el6xen.x86_64)
root (hd0,0)
kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin
kernel /vmlinuz-2.6.32.57-2.el6xen.x86_64 ro root=/dev/mapper/vg_xen-LogVol01 rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_xen/LogVol01 rd_LVM_LV=vg_xen/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32.57-2.el6xen.x86_64.img
title CentOS (2.6.32-279.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-279.el6.x86_64 ro root=/dev/mapper/vg_xen-LogVol01 rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_xen/LogVol01 rd_LVM_LV=vg_xen/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-279.el6.x86_64.img
when i reboot it is booted with xen kernel but when i run command
xm info or xm list
showing error
" Error: Unable to connect to xend: No such file or diectory. Is xend running "
when i run command
xend start
showing error
" xc: error: Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
xend/image.py: Error connecting to hypervisor "
ls /proc/xen
" ls: cannot access /proc/xen: No such file or directory "
added entry in /etc/fstab
Quote:
none /proc/xen xenfs default 0 0
after reboot gives error no such file or directory,
lsmod | grep -i xen output: Nothing...
modprob xen-evtchn
FATAL: Error inserting xen_evtchn (/lib/modules/2.6.32.57-2.el6xen.x86_64/kernel/drivers/xen/xen-evtchn.ko): No such device
modprob xen-gntdev
FATAL: Error inserting xen_gntdev (/lib/modules/2.6.32.57-2.el6xen.x86_64/kernel/drivers/xen/xen-gntdev.ko): No such device
I have enabled hardware virtulization in bios still problem not solved.
I tried another tutorial https://www.crc.id.au/xen-on-rhel6-scientific-linux-6-centos-6-howto/
it seems like nothing is working for me...
Guys... please share your thoughts about this problem...
Thank you.
i ran into this too in booting a Xen dom0 kernel.
i might have spotted one small omission in your grub.conf compared to the instructions.
in the grub config section at this line: "replace the first word initrd with module."
for example, here's my working Xen Dom0 grub.conf.
good luck!
default=0
timeout=2
title CentOS 6.3 Xen dom0
root (hd0,0)
kernel /boot/xen.gz loglvl=all guest_loglvl=all
module /boot/vmlinuz-dom0-kernel ro root=/dev/sda1 nomodeset console=ttyS0,115200 iommu=off earlyprintk=xen initcall_debug debug loglevel=10
module /boot/initrd-dom0-kernel.img
title CentOS 6.3 (No Xen)
root (hd0,0)
kernel /boot/vmlinuz-dom0-kernel ro root=/dev/sda1
initrd /boot/initrd-dom0-kernel.img
title Stock CentOS 6.3
root (hd0,0)
kernel /boot/vmlinuz-centos6.3 ro root=/dev/sda1
initrd /boot/initrd-centos6.3.img
This does the trick!
Check your boot entries in grub. I just upgraded my Centos 6.3 with the kernel-xen-3.5.3-1 to 3.7.1-3 and the new boot entry for this kernel gets wrong because between updates I installed a standard kernel for testing other things.
Fixing the correct boot options for xen brings back my virtualization!
title CentOS (3.7.1-3.el6xen.x86_64)
root (hd0,0)
kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=4 dom0_vcpus_pin
module /vmlinuz-3.7.1-3.el6xen.x86_64 ro root=UUID=<longUUID> KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 crashkernel=auto rhgb quiet
module /initramfs-3.7.1-3.el6xen.x86_64.img
I had the same issue:
Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
This was solved by adding the below line in /etc/fstab
none /proc/xen xenfs defaults 0 0
See this post in the Xen Project mailing list for more details.

Debug Linux kernel pre-decompression stage

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.

Resources