2019年8月18日 星期日

Linux Kernel(17)- Device Tree


Device tree是一個用來描述硬體的資料結構,包含了CPU、Memory、bus與周邊,DT改變了原本kernel的hard-code(table),改由bootloader傳入DTB(Device Tree Blob)給kernel。這個由SPARC-based開始的Open Firmware project於是慢慢地推廣到Arm, x86, MicroBlaze, PowerPC等平台。
這個有趣的故事可以讀一下Linux DTS(Device Tree Source)设备树详解之一(背景基础知识篇)

摘錄故事部分如下:
在Linux 2.6中,ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx,
比如板上的platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的
platform_data,这些板级细节代码对内核来讲只不过是垃圾代码。而采用Device Tree后,许多硬件的细节
可以直接透过它传递给Linux,而不再需要在kernel中进行大量的冗余编码。
每次正式的linux kernel release之后都会有两周的merge window,在这个窗口期间,kernel各个部分的
维护者都会提交各自的patch,将自己测试稳定的代码请求并入kernel main line。每到这个时候,Linus
就会比较繁忙,他需要从各个内核维护者的分支上取得最新代码并merge到自己的kernel source tree中。
Tony Lindgren,内核OMAP development tree的维护者,发送了一个邮件给Linus,请求提交OMAP平台
代码修改,并给出了一些细节描述:
       1)简单介绍本次改动
       2)关于如何解决merge conficts。有些git mergetool就可以处理,不能处理的,
         给出了详细介绍和解决方案。
一切都很平常,也给出了足够的信息,然而,正是这个pull request引发了一场针对ARM linux的内核代码
的争论。我相信Linus一定是对ARM相关的代码早就不爽了,ARM的merge工作量较大倒在其次,主要是他认为
ARM很多的代码都是垃圾,代码里面有若干愚蠢的table,而多个人在维护这个table,从而导致了冲突。
因此,在处理完OMAP的pull request之后(Linus并非针对OMAP平台,只是Tony Lindgren撞在枪口上了)
,他发出了怒吼:
     Gaah.Guys, this whole ARM thing is a f*cking pain in the ass.
 
之后经过一些讨论,对ARM平台的相关code做出如下相关规范调整,这个也正是引入DTS的原因。
1、ARM的核心代码仍然保存在arch/arm目录下
2、ARM SoC core architecture code保存在arch/arm目录下
3、ARM SOC的周边外设模块的驱动保存在drivers目录下
4、ARM SOC的特定代码在arch/arm/mach-xxx目录下
5、ARM SOC board specific的代码被移除,由DeviceTree机制来负责传递硬件拓扑和硬件资源信息。
本质上,Device Tree改变了原来用hardcode方式将HW 配置信息嵌入到内核代码的方法,改用bootloader
传递一个DB的形式。
 ———————————————— 
版权声明:本文为CSDN博主「RadianceBlau」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/RadianceBlau/article/details/70800076

bootloader傳入DTB(Device Tree Blob),而DTB是由Device Tree Source透過DTC編成的binary data,關係概略如下:

DTC相關用法可以參考dtc - Device Tree Compiler
DTS語法會在後面章節介紹,基本上,DTS只描述那些無法動態偵測的設備

    參考資料
  • https://blog.csdn.net/RadianceBlau/article/details/70800076, Linux DTS(Device Tree Source)设备树详解之一(背景基础知识篇)
  • https://en.wikipedia.org/wiki/Device_tree, Device tree
  • dtc - Device Tree Compiler




2019年7月13日 星期六

BuildID[sha1] of ELF


對於BuildID的解釋, 可以在ELF, Build-ID, is there a utility to recompute it?找到一段說明, 說明如下
I think things weren't very precisely formulated. If a tool changes the build that 
creates the ELF file so that it isn't a "semantically identical" binary anymore 
then it should get a new (recalculated) build-id. But if a tool changes something 
about the file that still results in a "semantically identical" binary then the 
build-id stays the same.

What isn't precisely defined is what "semantically identical binary" means. The 
intention is that it captures everything that a build was made from. So if the 
source files used to generate a binary are different then you expect different 
build-ids, even if the binary code produced might happen to be the same.

This is why when calculating the build-id of a file through a hash algorithm you
 use not just the (allocated) code sections, but also the debuginfo sections 
(which will contain references to the source file names).

But if you then for example strip the debuginfo out (and put it into a separate 
file) then that doesn't change the build-id (the file was still created from the 
same build).

This is also why, even if you knew the precise hashing algorithm used to calculate 
the build-id, you might not be able to recalculate the build-id. Because you might 
be missing some of the original data used in the hashing algorithm to calculate 
the build-id.

Feel free to share this answer with others.


內容簡略的說就是, BuildID是"semantically identical binary", 相同的semantic所build的program才會有相同BuildID.

brook@vista:~/01$ file src/hello
src/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=91439ef711a19bf3be7774d2c4af35746e098cc8, not stripped
brook@vista:~/01$ readelf -n src/hello

Displaying notes found at file offset 0x00000254 with length 0x00000020:
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32

Displaying notes found at file offset 0x00000274 with length 0x00000024:
  Owner                 Data size       Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 91439ef711a19bf3be7774d2c4af35746e098cc8
brook@vista:~/01$ strip src/hello
brook@vista:~/01$ file src/hello
src/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=91439ef711a19bf3be7774d2c4af35746e098cc8, stripped
brook@vista:~/01$ readelf -n src/hello

Displaying notes found at file offset 0x00000254 with length 0x00000020:
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32

Displaying notes found at file offset 0x00000274 with length 0x00000024:
  Owner                 Data size       Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 91439ef711a19bf3be7774d2c4af35746e098cc8

brook@vista:~/01$ make clean && make 重build也是會得到相同的BuildID
Making clean in src
...
brook@vista:~/01$ file src/hello
src/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=91439ef711a19bf3be7774d2c4af35746e098cc8, not stripped

brook@vista:~/01$ echo -e '\n\n\n' >> src/hello.c 即使多了幾行換行, 重build也是會得到相同的BuildID
brook@vista:~/01$ make
make  all-recursive
...
brook@vista:~/01$ file src/hello
src/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=91439ef711a19bf3be7774d2c4af35746e098cc8, not stripped


    參考資料:
  • https://stackoverflow.com/questions/41743295/elf-build-id-is-there-a-utility-to-recompute-it, ELF, Build-ID, is there a utility to recompute it?
  • https://fedoraproject.org/wiki/Releases/FeatureBuildId, Releases/FeatureBuildId





2019年7月7日 星期日

Using openembedded SDK to build protobuf-c


brook@vista:~/protobuf$ git clone git://github.com/google/protobuf.git
Cloning into 'protobuf'...
...

brook@vista:~/protobuf/protobuf$ git checkout 3.6.x
Branch 3.6.x set up to track remote branch 3.6.x from origin.
...

brook@vista:~/protobuf/protobuf$ . /opt/oecore-x86_64/environment-setup-cortexa7-neon-vfpv4-oe-linux-gnueabi


brook@vista:~/protobuf/protobuf$ vim configure.ac 
 export CFLAGS
 export CXXFLAGS
### remove below line ###
AC_CONFIG_SUBDIRS([third_party/googletest])

brook@vista:~/home6t/protobuf/protobuf$ ./autogen.sh
+ mkdir -p third_party/googletest/m4
+ autoreconf -f -i -Wall,no-obsolete
...

brook@vista:~/protobuf/protobuf$ ./configure ${CONFIGURE_FLAGS} --prefix=/home/brook/protobuf/
configure: loading site script /opt/oecore-x86_64/site-config-cortexa7-neon-vfpv4-oe-linux-gnueabi
checking whether to enable maintainer-specific portions of Makefiles... yes
checking build system type... x86_64-pc-linux-gnu
...

brook@vista:~/protobuf/protobuf$ make all -j 8
make  all-recursive
Making install in .
make[1]: Entering directory '/home/brook/protobuf/protobuf'
...

brook@vista:~/protobuf/protobuf$ make install
Making install in .
make[1]: Entering directory '/home/brook/protobuf/protobuf'
...


change "/home/brook/protobuf/lib/libprotoc.la"
from
# Libraries that this one depends upon.
dependency_libs=' =/home6t/brook/protobuf/lib/libprotobuf.la =/usr/lib/libstdc++.la'

to
# Libraries that this one depends upon.
dependency_libs=''


brook@vista:~$ mkdir protobuf-c
brook@vista:~$ cd protobuf-c
brook@vista:~/protobuf-c$ git clone git://github.com/protobuf-c/protobuf-c.git
Cloning into 'protobuf-c'...
remote: Enumerating objects: 59, done.
remote: Counting objects: 100% (59/59), done.
...

brook@vista:~/protobuf-c/protobuf-c$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
...

brook@vista:~/protobuf-c/protobuf-c$ PROTOC=/usr/bin/protoc-c protobuf_CFLAGS="-I/home/brook/protobuf/include" protobuf_LIBS="-L/home/brook/protobuf/lib" ./configure ${CONFIGURE_FLAGS} --prefix=/home/brook/protobuf-c
configure: loading site script /opt/oecore-x86_64/site-config-cortexa7-neon-vfpv4-oe-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...

brook@vista:~/protobuf-c/protobuf-c$ make -j 8
make  all-am
make[1]: Entering directory '/home/brook/protobuf-c/protobuf-c'
  CC       protobuf-c/protobuf-c.lo
...

熱門文章