U-Boot Updates Device Tree Blob

When u-boot a kernel image with device tree blob, like
bootz 0x0a000000 - 0x09f00000
( 0x0a000000 is the location of the zImage, 0x9f00000 is the location of device tree blob)

The device tree blob is not passed to kernel as it is, the u-boot will fix up some value like memory bank range and size in the device tree blob.
For memory fix up, it is done in
arch_fixup_fdt, file arch/arm/lib/bootm-fdt.c

Play U-Boot on Qemu, 2015 version

Package Installation
  sudo apt-get install qemu-system  gcc-arm-none-eabi
  sudo apt-get -o Dpkg::Options::="--force-overwrite" install gdb-arm-none-eabi


U-Boot Build

Get u-boot source from ftp://ftp.denx.de/pub/u-boot/ , I got version u-boot-2015.01.tar.bz2

Extract the source and on console:

  cd u-boot-2015.01

  make versatileqemu_config ARCH=arm CROSS_COMPILE=arm-none-eabi-

  make all ARCH=arm CROSS_COMPILE=arm-none-eabi-
To print out the actual compile and linker command:
  make all ARCH=arm CROSS_COMPILE=arm-none-eabi- KBUILD_VERBOSE=1

Run the U-Boot in Qemu

  qemu-system-arm -M versatilepb -m 128M -nographic -kernel u-boot.bin

You should see U-Boot prompt "VersatilePB # " on the console

To exit QEMU, press “Ctrl a” and then “x”.

Problem Shooting

Run with logging every instruction exectuted

  qemu-system-arm -M versatilepb -m 128M -nographic -kernel u-boot.bin -d in_asm,cpu -D qemu.log -singlestep

Disassemble U-Boot

  arm-none-eabi-objdump -d u-boot

Check memory map info
  gvim u-boot.map
  nm u-boot

To Clean
  make clean
  make mrproper

To enable debug message
in include/configs/versatial.h
add
#define DEBUG 1


Debug with GDB 
Install the gdb for arm

 sudo apt-get -o Dpkg::Options::="--force-overwrite" install gdb-arm-none-eabi

qemu-system-arm  -m some_machine -m 256M -nographic -kernel some_image.bin -s

on the other terminal

ddd --debugger arm-none-eabi-gdb
(gdb) symbol-file ~/git/lhx/vmlinux
(gdb)
(gdb) target remote :1234
(gdb) break setup_arch
(gdb) c

Reference

https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/DUI0224I_realview_platform_baseboard_for_arm926ej_s_ug.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183g/DDI0183G_uart_pl011_r1p5_trm.pdf http://git.savannah.gnu.org/cgit/qemu.git/tree/hw/versatilepb.c
https://balau82.wordpress.com/2010/11/30/emulating-arm-pl011-serial-ports/
http://elinux.org/Virtual_Development_Board

Debug U-Boot After Relocation

U-Boot will relocate itself during the startup. But the symbol data in u-boot was still based on the information before relocate.

This is how I debug U-Boot after relocation with ARM DS-5 debugger

1. Find out where U-Boot is relocated to
Add below to your board configuration header, like "include/configs/versatile.h" to enable the debug output.
#define DEBUG 1

2. When U-Boot starts to run, debug information will be printed out like below
...
relocation Offset is: 03fd0000
...
Now running in RAM - U-Boot at: 0bfd0000 
This indicates the relocation offset to original load address is 0x03fd0000

3. Load the symbol with
On ARM DS-5 debugger command window,
symbol-file
add-symbol-file "C:\svn\HRTK1041\bld\u-boot" 0x3fd0000
First command is to discard the current symbol table
Second command is to load the actually symbol data with offset.
Now, happy debugging.


Reference
http://www.denx.de/wiki/view/DULG/DebuggingUBoot

U-Boot boot image

Command "bootm" will boot the image. 

// entry point to handle bootm command
do_bootm() 
  // get the boot image meta data information
  // image header info are in structure image_header
  bootm_start
    // entry point address
    images.ep = image_get_ep(&images.legacy_hdr_os_copy);
    // os load address, after unzip
    images.os.load = image_get_load(os_hdr);
  // load os image
  bootm_load_os
    // un-compress image to os.load address
    gunzip
  // when booting linux, boot_fn points to do_bootm_linux, 
  // for ARM, function implemented in arch/arm/lib/boom.c
  boot_fn
    // jump to the linux kernel
    boot_jump_linux
      kernel_entry = (void (*)(int, int, uint))images->ep;
      kernel_entry(0, machid, r2);

U-Boot SPL

What is SPL?

SPL: Secondary Program Loader

Unlike NOR flash, many boot sources are not directly memory mapped.

On-chip ROM or other mechanism loads a binary into an SRAM.
  – This SRAM is often very small, sometimes 4 KiB or less.
  – The ROM can't load us into main system RAM yet, since initialization is too complex and must be handled by U-Boot.

SPL (Secondary Program Loader) is a small binary, generated from U-Boot source, that fits in the SRAM and loads the main U-Boot into system RAM.

Configured by a parallel set of makefile config symbols
  –  CONFIG_SPL_I2C_SUPPORT, CONFIG_SPL_NAND_SUPPORT, etc.
  – Normal CONFIG symbols also used, but not to control the differences between the SPL and the main U-Boot.
  – SPL also relies heavily on toolchain garbage collection.

Reference
http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/tpl-presentation.pdf