grep linux

http://askubuntu.com/questions/319951/recursive-grep-fails-for-c-files

find . -name "*.c" -print0 | xargs --null grep -l search-pattern

find . -name "*.c" -exec grep -l search-pattern "{}" \;

資料救援軟體 2016

final data
http://www.finaldata.com/

資料恢復-EasyRecovery 11.0.2.0 多國語言免安裝
https://softblog.tw/easyrecover.html


Recover My Files
http://www.recovermyfiles.com/
http://www.softking.com.tw/soft/clickcount.asp?fid3=22954


Drive Rescue 1.9D
http://drive-rescue.en.lo4d.com/
http://www.softking.com.tw/soft/clickcount.asp?fid3=17095


recuva recuva file recovery (piriform)
https://www.piriform.com/recuva

R-studio
http://www.r-studio.com/
https://briian.com/29042/r-studio.html


new live all media fixer
http://www.softking.com.tw/soft/clickcount.asp?fid3=22017
http://www.realconvert.com/all_media_fixer_2008_pro.htm

-----------------------------------------------------------------------------------------------
http://support.wdc.com/downloads.aspx?lang=en

support -> software&downloads -> wd software ->

Data Lifeguard Diagnostic for Windows
File Size: 975 KB

mips knowledge(pic/gp/t9)

https://nieyong.github.io/wiki_ny/mips%20knowledge.html
global pointer

全局指针寄存器(gp)是MIPS的通用寄存器$28。这个寄存器的用途主要有两种：


http://lists.denx.de/pipermail/eldk/2007-November/000014.html
[ELDK] Crosstool for MIPS exception in "run time"


http://stackoverflow.com/questions/6835724/mips-stack-frame-and-addiu-instruction-confusion
Question #1:
Despite searching around for awhile on the internet, I still don't really understand how gp is supposed to be used in the stackframe.

In particular, the documents I read say the call procedure standard is a0-a3 are used as function input, v0-v3 as function output, s0-s8 are preserved across calls, and t0-t9 are not preserved across any call. So the pushing and popping of s0-s8 make sense. But why in the world is it setting gp according to the value in t9!?



http://www.linux-mips.org/wiki/PIC_code

A quick PIC howto



https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39493
Bug 39493 - [Mips] No space for arguments when implicitely calling __get_tls_addr

Compiled and linked with:

mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno-builtin -mips2 -EL -mabicalls -G0 -c -o test.o test.c
mipsel-unknown-elf-ld -shared test.o -o test.so

Result in assembly:

5ffe0390 <func>:
5ffe0390:       3c1c0001        lui     gp,0x1
5ffe0394:       279c9090        addiu   gp,gp,-28528
5ffe0398:       0399e021        addu    gp,gp,t9
5ffe039c:       27bdffe8        addiu   sp,sp,-24



http://www.linux-mips.org/wiki/NPTL

Status

NPTL for Linux/MIPS is functionally complete. Ulrich Drepper's NPTL Design Document contains some information on the NTPL design including implementation details on other architectures. One prerequirement for NPTL is TLS, as documented in Thread Local Storage.


https://sourceware.org/ml/binutils/2013-02/msg00121.html

[9/20] MIPS GOT: Factor out GOT creation code

The master GOT and multigots use different hash equivalence functions,
and hence different hash functions.  The master GOT has a separate
mips_got_entry for each BFD that references a symbol, and a separate
mips_got_entry for each BFD that uses a TLS LDM slot.  Other GOTs have
a single mips_got_entry for all references to the same thing.


https://www.math.ku.edu/computing/cluster/totalview.6.0.0-0-doc/ref_guide/architectures24.html

MIPS General Registers

TotalView displays the MIPS general-purpose registers in the Stack Frame Pane of the Process Window. The following table describes how TotalView treats each general register, and the actions you can take with each register.

Programs compiled with either -64 or -n32 have 64-bit registers. TotalView uses <long> for -64 compiled programs and <long long> for -n32 compiled programs.


https://www.sourceware.org/ml/binutils/2004-05/msg00622.html

Re: [patch] MIPS gas problems with gcc's explicit relocs

uboot relocate pic

http://u-boot.10912.n7.nabble.com/why-u-boot-relocate-it-self-to-RAM-from-flash-td168729.html


Hi,

I can not understand why u-boot relocate it self to RAM from flash? Why is
it not executing from flash?
Can anybody explain.



There is a ton of reasons.  One is that you cannot erase or program
the flash device and execute code from it at the same time, so we
would not be able to write a Linux kernel image - at least not without
special flash drivers that execute from RAM.  And we would not be able
to update the U-Boot image in flash. etc. etc.

In the end it is much easier to run from RAM.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]



http://blog.xuite.net/tzeng015/twblog/113272412-MIPS+u-boot+%E4%B8%ADcode+Relocate%E6%B5%81%E7%A8%8B%E5%88%86%E6%9E%90


注釋：

0xbf000000 是mips 24kc Flash起始的位置，也是reset

0x80000000是ar9132平台DDR的起始位置。

鏈接腳本中的0x00000000會被這個TEXT_BASE替代，可以觀察編譯時候的輸出，你會發現有一個-DTEXT_BASE=0xbf000000的選項。



Relocate的代碼在start.S中。

啟動的大致順序如下，假設代碼固化於flash起始位置。

       CPU 上電

       Reset(初始化cp0寄存器)         

       設置GOT

       lowlevel_init(初始化SDRAM)

       初始化cache

       Relocate代碼



下面是代碼的入口

       la  t9, board_init_f

          j   t9

          nop

這個board_init_f定義在lib_mips/board.c中。

這個程序為下列元素分配合適的內存空間：

[1] u-boot代碼（.text .data .bss）

[2] malloc空間 （相當於heap）

[3] Board Info

[4] Global Data

[5] Stack

這里可以看出malloc的空間位於heap中，即內存的高端，而函數中的局部變量，都在stack中的，在內存低端。

                                        

void board_init_f(ulong bootflag)

{

       gd_t gd_data, *id;

       bd_t *bd;

       init_fnc_t **init_fnc_p




https://lxr.missinglinkelectronics.com/#uboot/doc/README.qemu-mips
 uboot/doc/README.qemu-mips



http://www.linuxjournal.com/content/handy-u-boot-trick

Figure 1 shows the default boot sequence of the BeagleBone Black. This sequence is more or less applicable to most embedded systems. The x-loader and U-Boot executables are stored in the files called MLO and uboot.img, respectively. These files are stored in a FAT32 partition. The serial port outputs of the BeagleBone are shown in Listings 1–3.



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


10.1.2. Debugging of U-Boot After Relocation

For debugging U-Boot after relocation we need to know the address to which U-Boot relocates itself to. When no exotic features like PRAM are used, this address usually is <MAXMEM> - CONFIG_SYS_MONITOR_LEN. In our example with 16MB RAM and CONFIG_SYS_MONITOR_LEN = 192KB this yields the address 0x1000000 - 0x30000 = 0xFD0000.

In other cases, check the source code, and apply some common sense. For example, on Power Architecture® we use "r2" to hold a pointer to the "global data" structure ("struct global_data"); this structure contains a field

unsigned long   relocaddr;      /* Start address of U-Boot in RAM */

which is the start addresses of U-Boot after relocation to RAM. You can easily print this value in gdb like that:

(gdb) print/x ((gd_t *)$r2)->relocaddr

With this knowledge, we can instruct gdb to forget the old symbol table and reload the symbols with our calculated offset:

(gdb) symbol-file



http://stackoverflow.com/questions/9415724/questions-about-u-boot-relocation-feature


I am using the u-boot-2011.12 on my OMAP3 target, the cross tool chain is CodeSourcery arm-none-linux-gnueabi, I compiled u-boot, downloaded it onto the target and booted it, everything went fine,but I have some questions about the u-boot relocation feature, we know that this feature is base on PIC(position independent code), position independent code is generated by setting the -fpic flag to gcc, but I don't find fpic in the compile flags. Without the PIC, how can u-boot implement the relocation feature?




http://blog.csdn.net/skyflying2012/article/details/37660265


最近在一直在做uboot的移植工作，uboot中有很多值得学习的东西，之前总结过uboot的启动流程，但uboot一个非常核心的功能没有仔细研究，就是uboot的relocation功能。

这几天研究下uboot的relocation功能，记录在此，跟大家共享。

自己辛苦编辑，转载请注明出处，谢谢！


所谓的relocation，就是重定位，uboot运行后会将自身代码拷贝到sdram的另一个位置继续运行，这个在uboot启动流程分析中说过。

但基于以前的理解，一个完整可运行的bin文件，link时指定的链接地址，load时的加载地址，运行时的运行地址，这3个地址应该是一致的

relocation后运行地址不同于加载地址 特别是链接地址，ARM的寻址会不会出现问题？