А проблемът описан ли е някъде писмено?

Мисля че открих къде е проблема. tftp сервиза не сервира файлове и връща таймаут защото не е стартиран с root права.

sudo ./rc.opentftp restart

Това трябва да оправи проблема(поне при мен стана)

Ако напишем

./opentftpd -v

TFTP Server SinglePort Version 1.66 Unix Built 2003
.
.
.
127.0.0.1 Port 69 bind failed, Permission denied
192.168.1.51 Port 69 bind failed, Permission denied
No Static Interface ready, Waiting...
Retrying failed Listening Interfaces..
detecting Interfaces..
127.0.0.1 Port 69 bind failed, Permission denied
192.168.1.51 Port 69 bind failed, Permission denied
.
.
.

Казва че няма пермишени за портовете. Като използваме sudо всичко пише че е ОК.

И така в виртуалната машина като напишем tftpboot спира да изписва "TTTTTTT..." тоест Timeout

След много много опити и ровене в нета успях да прескоча проблема с зареждането на Linux ядрото от U-Boot в QEMU. Важни се оказаха версията на u-boot и една особеност при конфигурирането: (u-boot-2015.07.tar.bz2 и versatileqemu_defconfig)

Стъпки:

--- Cross compile U-Boot ---

$ cd /opt
$ wget ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2
$ tar xvfj u-boot-2015.07.tar.bz2

- in order to enable the bootz command (boot Linux zImage image from memory), you need to add:
   #define CONFIG_CMD_BOOTZ
   in your board config file (include/configs/)

$ cd u-boot-2015.07
$ make ARCH=arm CROSS_COMPILE=/opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- versatileqemu_defconfig
$ make ARCH=arm CROSS_COMPILE=/opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-

  'u-boot' и 'u-boot.bin' ще бъдат генерирани в /opt/u-boot-2015.07/

Използвах buildroot за генериране на файловете с Linux ядрото и файловата система. Получения файл е zImage а не uImage и заради това беше необходимо да добавя в един от .h файловете на u-boot (versatile.h) #define CONFIG_CMD_BOOTZ и сега вече u-boot поддържа зареждане на zImage.

$ wget https://buildroot.org/downloads/buildroot-2015.11.1.tar.bz2
$ tar xvfj buildroot-2015.11.1.tar.bz2
$ make qemu_arm_versatile_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

Маркирайте:

1. Busybox Settings -> Build Options -> Build BusyBox as a static binary (no shared libs) option.
2. Filesystem images -> [*] initial RAM filesystem linked into linux kernel

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

Получените файлове преместете в директорията на TFTP сървъра.

Всички останали стъпки са според описанието на Мартин.

Когато зареди u-boot аргументите които използвах са:

VersatilePB # setenv autoload no
VersatilePB # dhcp
VersatilePB # setenv serverip 192.168.88.2
VersatilePB # setenv bootfile zImage
VersatilePB # setenv bootargs root=/dev/sda rw initrd=rootfs.ext2 rdinit=/sbin/init ip=dhcp mem=128M console=ttyAMA0,115200
VersatilePB # tftpboot
VersatilePB # bootz

Резултат: http://pastebin.com/dVFhr8N6

Остава да се направи зареждането на файловата система, но не намирам лесен и удобен начин това да стане през TFTP ако такава е целта на задачата. Ще го направя през NFS Server, но засега толкова.

Всеки Linux/Unix, след като зареди кернела в паметта, търси да намети / 'root' файлова система или 'initrd image'  в паметта. След като намери каде е '/' фаиловата състем първото нещо, което прави е да стартира процес с PID =1 и това е /sbin/init. Този процес от своя страна се грижи да се стартира цялата конфигураця на състемата като кернел модули, ip адрес , services , и.т.н. Може  да се зареди шел вместо init процеса например , като спрем боотването в grub и да радактираме конфигурацята времено и да добаваим опция към реда с кернела ....init=/bin/bash .... Така вместо init процеса,  след като  се зареди кернела ще стартира root shell.   

В този конкретен случай с qemu arm виртуалицацията трабва да  намерим от някъде подходящ initrd image   и при стартирането на виртуалната машина да добавим опциите:

sudo /opt/qemu/bin/qemu-system-arm -M versatilepb -nographic -net nic -net tap,ifname=tap0 -kernel /home/orhi/u-boot-2010.09/u-boot -initrd ~/initramfs-linux.img 

или друг вариянт е да боотнем от dd image: кернела, фаиловата състема и всички конфигурациони файлове. 

sudo /opt/qemu/bin/qemu-system-arm -M versatilepb -nographic -hda disk.img -net nic -net tap,ifname=tap0

И така ще имаме login промпт или рабодеща система под някаква форма. 

Причината за "зависването" е "-nographic" опцията:

http://wiki.qemu.org/download/qemu-doc.html

"Normally, QEMU uses SDL to display the VGA output. With this option, you can totally disable graphical output so that QEMU is a simple command line application. The emulated serial port is redirected on the console. Therefore, you can still use QEMU to debug a Linux kernel with a serial console"

Тоест ако искаме да виждаме изхода от boot-a на кернела (не зависимо дали е успял или не) слагаме в bootargs console=ttyAMA0 и така целия изход се пренасочва към текущия терминал и виждаме какво става с boot-a.

sete bootargs ${bootargs} console=ttyAMA0