TFTP + NFS boot openrd-ultimate

TFTP + NFS boot openrd-ultimate

1, install Debian in USB as described in http://www.cyrius.com/debian/kirkwood/openrd/install.html

2, after success installation, login to Debian system

3, edit /etc/initramfs-tools/initramfs.conf, find "BOOT=local", change it to "BOOT=nfs";

4, issue "update-initramfs -u" to get new /boot/uImage and /boot/uInitrd.

5, shutdown the system, copy the base system to /opt/openrd/nfs, which is exported via NFS.
5.1, Edit /opt/openrd/nfs/etc/fstab to comment out all local mount since there is no local file system after NFS boot. Otherwise, debian would try to mount root file system again after NFS boot

6, copy /opt/openrd/nfs/boot/{uImage,uInitrd} to /opt/openrd/tftp/{uImage,uInitrd}

7, start Openrd-Ultimate, enter u-boot, set environments
set mainlineLinux yes
set arcNumber 2884
set ipaddr=192.168.1.2
set serverip=192.168.1.1
set console 'console=ttyS0,115200n8'
set nfs 'mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/nfs rw nfsroot=192.168.1.1:/opt/openrd/nfs'
set ip 'ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB88FXX81:eth0:none'
set bootargs $(console) $(nfs) $(ip)
set bootcmd 'tftpboot 0x01100000 uInitrd; tftpboot 0x00800000 uImage; bootm 0x00800000 0x01100000'
saveenv
reset

8, After restart, should be able use tftp to load uImage and uInitrd, and mount NFS directory /opt/openrd/nfs as root filesystem

libquantum problem

libquantum has performance lost

why?

Check ibtc and shack hit ratio
they are the same!

don't know
check all version!

segmentation fault:
1' where?
0x00007fffe0000158
0x00007fffe8000168
0x00007fffe8000078
0x00007fffe0000158

This address seems strange
jit_event_listener

try debug version

turn off AddShackPush in trace, wait and see...
still seg fault, re-implement
should always try both single thread version, multi-thread version

Reason:
timing plus inappropriate block_map
when translating a block, the block info is inserted into block_map
at beginning of translation process, which violates the assumption of block map.
We assume all infos in block map are valid, which means they have host code address where the translated code at. However, at the beginning of translation, we didn't know the exact address of the translated block. As a result, when the trace builder doing AddShackPush, it found the incomplete block in the block map, and uses its address.
Therefore, we modified the code as the following:
1. block info is added immoderately after the location of the translated block is known, which is in NotifyFunctionEmitted of jit_event_listener.h.
2. the query is delayed until we are going to patch the shack point.

However, in this experiment, I found shadow stack is quietly in-effect to performance,
plus it consumes more memory, and makes code complex. It seems more reasonable not to use shack when trace is available.