find 확장 조합 (grep , xarg)

1. Linux 에서 검색방법

개별 find or grep으로 검색으을 하면, 어느정도의 한계를 느낄 것이며, 이를 확장해주는 것이 xargs의 기능이라고 생각한다.
이를 pipe라는 기능을 사용하여, '|'  조합으로 기본 구성을 하여 사용해보고, 단순 검색인
find와 grep을 이용을 해보자.


1.1 find 이용한 기본 검색 

• find name 검색 

$ find . -name board // kernel 에서 board  filename 검색 
./Documentation/devicetree/bindings/board
./drivers/staging/board

$ find . -name '*.c' // *.c file 파일 검색 
.....

• find로 변경시간 검색 

-5 or -10 , 즉 5분 전 or 5일 전 것이 가장 유용하게 이용이 될것이며, 파일이 많으면,
head or tail 이용하자

-cmim :  File의 status가 변경된 시간 (기준 n minute)
-ctime :  File의 status가 변경된 시간 (기준 n*24 hours, 1 day)
-mmin:   File의 data가 변경된 시간 (기준 n minute)
-mtime:  File의 data가 변경된 시간 (기준 n*24 hours , 1 day )

$ find . -cmin -5 //  -5 분이하, 즉 5분전  파일 변경된 것 검색 
./.config

$ find . -cmin 5         //  정확히 5 분 전 것만 검색 , 별로 검색에 필요 없음 
$ find . -cmin +5 | head //  +5 분이상, 즉 5분 후  파일 변경된 것 검색 , 파일이 너무 많아 head 사용 
./.tmp_kallsyms2.o
./mm
./mm/.filemap.o.cmd
./mm/.mincore.o.cmd
./mm/mremap.o
./mm/.compaction.o.cmd
./mm/page_isolation.o
./mm/.msync.o.cmd
./mm/modules.builtin
./mm/zsmalloc.c  

$ find . -ctime -5   //  파일 변경된 것 -5 *24 시간 이하     , 즉 5일 이전것 
.
./init
./include/linux
./kernel/sched
./arch/arm/boot/compressed
./arch/arm/kernel
./.config.old

$ find . -ctime 5    //  파일 변경된 것 5*24 hours 시간된 것 ,
$ find . -ctime +5   //  파일 변경된 것 +5 *24 hours 시간이상, 즉 5일 이후것  

atime /amin : 즉 access time 도 존재하지만 , debugging 할 경우에나 필요할 것 같다.

• find로 size 기준으로 검색 

find로 file size 기준으로 검색

$ find -size -512c  // 512 byte 이하 검색 
$ find -size -4k  // 4k byte 이하 검색 
$ find -size -4M  // 4M byte 이하 검색 
$ find -size -4G  // 4G byte 이하 검색 

• grep을 이용한 검색 

grep을 이용하며, 검색하면 좋지만, 시간 상당히 걸리뿐만 아니라
가끔 시스템이 죽을 경우도 존재한다.

$ grep -n _board_ ./System.map // System.map 파일 안에서 _board_ 검색하고 line을 출력 
$ grep -n _board_ ./System.map 
678:c001ff70 t omap_mux_dbg_board_open
680:c001ffc0 t omap_mux_dbg_board_show
18680:c043faf0 T spi_register_board_info
28085:c0679ecc r omap_mux_dbg_board_fops
37105:c088aeb8 R __ksymtab___i2c_board_list
37106:c088aec0 R __ksymtab___i2c_board_lock
45157:c08964c8 r __kcrctab___i2c_board_list
45158:c08964cc r __kcrctab___i2c_board_lock

$ grep -r _board_ .              // 현재 directory부터 모든 파일 안의 _board_  검색을 한다 
./System.map:c001ff70 t omap_mux_dbg_board_open
./System.map:c001ffc0 t omap_mux_dbg_board_show
./System.map:c043faf0 T spi_register_board_info
./System.map:c0679ecc r omap_mux_dbg_board_fops
./System.map:c088aeb8 R __ksymtab___i2c_board_list
./System.map:c088aec0 R __ksymtab___i2c_board_lock
./System.map:c08964c8 r __kcrctab___i2c_board_list
./System.map:c08964cc r __kcrctab___i2c_board_lock
./System.map:c08b2e64 r __kstrtab___i2c_board_list
./System.map:c08b2e75 r __kstrtab___i2c_board_lock
./System.map:c08cc7d4 T omap_serial_board_init
./System.map:c08e73c4 T i2c_register_board_info
./System.map:c08fc398 t pmic_i2c_board_info
./System.map:c0911390 d musb_default_board_data
./System.map:c0945560 D __i2c_board_lock
./System.map:c094556c D __i2c_board_list
.....

1.2. 기본조합 (find와 grep)

find만 이용할 경우 file list 만을 검색을 하지만, 여기서 grep을 이용하여 file list를 

find에서 검색한 list 에서만, grep을 이용하여 find의 검색 정보의 정확성을 높힌다.
사실 그리 좋은 조합은 아닌 것 같다.

1. find 로 *.c 파일 file list을 생성
2. *.c file list 입력을 받아 이를 grep 으로 board관련된 내용 file list 줄임

$ find . -name '*.c' | grep board  // find 로 전체 *.c 파일 list 생성
./sound/soc/intel/boards/haswell.c
./sound/soc/intel/boards/skl_rt286.c
./sound/soc/intel/boards/bytcr_rt5640.c
./sound/soc/intel/boards/byt-max98090.c
./sound/soc/intel/boards/broadwell.c
./sound/soc/intel/boards/cht_bsw_rt5645.c
./sound/soc/intel/boards/cht_bsw_max98090_ti.c
./sound/soc/intel/boards/mfld_machine.c
./sound/soc/intel/boards/cht_bsw_rt5672.c
./sound/soc/intel/boards/byt-rt5640.c
./kernel/debug/kdb/kdb_keyboard.c
./arch/arm/mach-tegra/board-paz00.c
./arch/arm/mach-omap2/board-generic.c
./arch/arm/mach-omap2/board-ldp.c
./arch/arm/mach-omap2/board-rx51-peripherals.c
./arch/arm/mach-omap2/common-board-devices.c
./arch/arm/mach-omap2/board-n8x0.c
./arch/arm/mach-omap2/board-rx51.c
./arch/arm/mach-omap2/board-rx51-video.c
./arch/arm/mach-omap2/board-flash.c
./arch/arm/mach-ux500/board-mop500-audio.c
./arch/arm/mach-ux500/board-mop500-regulators.c
./arch/arm/mach-omap1/board-h2-mmc.c
./arch/arm/mach-omap1/board-perseus2.c
./arch/arm/mach-omap1/board-osk.c

1.3 find 와 xargs 와 greps 조합 검색

• xargs 와 pipe의 조합기능 

 xargs - build and execute command lines from standard input
 xargs는 stdin으로 부터 들어온 command lines을 실행하거나 빌드하는 기능이다.

쉽게 말하면

1. find  *.c   |  xargs grep xx  // c파일을 찾아 list 만들고 이를 grep에게 argument로 전달 
2. find  *.h  |  xargs rm    xx  // h파일을 찾아 list 만들고 이를 rm에게  argument로 전달 

xargs를 이용하여, grep으로 검색을 하되 find에서 검색한 내용안 에서만 검색을 한다.
위의 검색과  차이가 있다.

$ find . -name '*.c' | xargs grep dram_init   // *.c 검색해서  grep으로 *.c파일만 dram_init 내용을 검색 

1.4. xargs 확장 사용 

xargs: 파이프 이전의 명령의 결과 값들을 인자로 보내어 주어 실행시킴.
이름도 xargs , 현재 여러 인자를 TEST 못해봄.  주로, 인자 하나만 사용해봄.

$ find . -name '*.o' | xargs  grep 찾고자 하는 file 
$ find . -name '*.mk' -o -name 'Makefile' | xargs grep odroid 
$ find . -name '*.mk' | xargs rm 

Ref.
  http://stackoverflow.com/questions/7339253/find-and-number-of-days-range
  http://qdata.co.kr/bo/bbs/board.php?bo_table=ltip&wr_id=210


2. 소스내 패턴검색 (sed,xarg 응용)

sed를 알고나서, xarg에 적용을 하고 난뒤 아래와 같은 조합으로 만들어봤는데,
소스검색방법으로 정말 최적인것 같다.
SSD가 아닌곳에서도 소스검색용으로는 최적인것 같다.


sed 및 xargs와 grep를 이용하여, 빌드만 된 소스에서 원하는 패턴을 검색

      1. find로  obejct 검색한다.
      2. sed 로 *.o 에서 *.c로 변경한다. (검색결과 파이프로 받는다)
      3. xargs를 이용하여 grep 명령을 실행한다. (-r 재귀명령어, -s  no-messages )

$ find . -name '*.o' | sed -e 's/o$/c/g' | xargs grep -rs 'stmmac'

3. Find 기타사용

• 소스 파일 추출  (cscope 파일 사용)

Find 사용하여, 소스 File 추출

$ find . \( -name '*.c' -o -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.s' -o -name '*.S' -o -name '*.asm' \) -print > cscope.files 

ex) 특정 파일 추출

    하나 추가할때마다 -o -name 사용

$ find . -name '*.c' -o -name '*.h' 

ls 하여 파일을 다시 grep으로 avc포함된 파일만  ./avc 폴더로 이동

$ ls | grep avc | xargs -i mv {} ./avc  

  https://kldp.org/node/35902

xargs 기본사용

1. xargs 기본사용

xargs는 기본적으로 단독으로 사용하는 command가 아니며 다른 command과 조합으로 사용한다.

xargs에서 다른 command를 실행하면, 표준입력으로 값으로 들어온 값을 그대로 command로 넘겨준다. 그래서 이름 xargs 인 것 같다.
결론적으로 xargs의 command는 표준입력의 넘어온 list의 제한적인 검색 또는 실행을 한다.

$ find . -name "*.o" | xargs rm -rf  

SYNOPSIS
       xargs  [-0prtx] [-E eof-str] [-e[eof-str]] [--eof[=eof-str]] [--null] [-d delimiter] [--delimiter delimiter] [-I replace-str] [-i[replace-str]] [--replace[=replace-str]] [-l[max-lines]]
       [-L max-lines] [--max-lines[=max-lines]] [-n max-args] [--max-args=max-args] [-s max-chars] [--max-chars=max-chars] [-P max-procs]  [--max-procs=max-procs]  [--interactive]  [--verbose]
       [--exit] [--no-run-if-empty] [--arg-file=file] [--show-limits] [--version] [--help] [command [initial-arguments]]

2. 기본예제

$ find . -name "*.o" | xargs rm -rf
$ ls "*.o" | xargs rm -rf

위 예제가 제대로 동작이 안될 때 아래와 같이 한다.
왜냐하면 find를 검색은 기본적으로 newline을 포함하지만 -print0 은 이를 제거한다.

$ find /tmp -name "*.tmp" -print0 | xargs -0 rm

• 각 directory의 전체 사이즈를 알고 싶을 경우.

$ ls | xargs du -hs 

http://www.dreamy.pe.kr/zbxe/CodeClip/164220
http://www.thegeekstuff.com/2013/12/xargs-examples/

Device Tree 기반 소스수정 및 빌드 (U-Boot 와 Kernel)

1. Device Tree의 DTS 기본구조 및 Build 

Device Tree Syntax의 약자이며, Kernel 와  Uboot에 존재하며, 보통 두개의 dts 파일은 동일하다

1. Kernel PATH:  arch/arm/boot/dts 
2. Uboot PATH:  arch/arm/dts/

Device Tree Boot 방식
  https://ahyuo79.blogspot.com/2015/08/am437x-kernel-device-tree.html
  https://ahyuo79.blogspot.com/2015/08/device-tree-2-am437xam335x.html

Device Tree Syntax 구성방법
  https://ahyuo79.blogspot.com/2015/08/device-tree.html

지향하는 바는 DTS를 한번 설정하면 손쉽게 Uboot 와 Kernel 의 HW 설정변경 가능하도록하는 것이다.
물론 예외적으로 보면, 각 Image들과 결합을 하게되어 사용을 한다면, 따로 사용도 가능하겠다.

DTSI와 DTS파일이 존재하며, DTSI는 DTS에서 include하는 파일이며, 구조 또한 동일하다.
하지만, dt-bindings도 include를 하지만 header 파일로 사용이 된다.

Build 전에는 DTS와 DTSI만 존재하지만, Build 후에 DTB가 생성이된다.

1. Main files: ./arch/arm/boot/dts 
2. Include Files: ./arch/arm/boot/dts/include/dt-bindings
3. Makefile: ./arch/arm/boot/dts/Makefile

1.1 AM437x Example

AM437x-GP-EVM 을 사용을 하며 TEST을 하고 있다.

$ ls arch/arm/boot/dts/am4*
am4372.dtsi             am437x-gp-evm.dtb  am437x-sk-evm.dtb  am43x-epos-evm-hdmi.dts  am43x-epos-evm.dts
am437x-gp-evm-hdmi.dts  am437x-gp-evm.dts  am437x-sk-evm.dts  am43x-epos-evm.dtb       am43xx-clocks.dtsi 

1.2 I.MX6 인 Example

I.MX6를 수정을 할때, 참고하던 Device Tree 예제들이며, 현재 Device Tree로 대부분의 CPU들이 지원을 하는 것 같다.
특히 한 것은 pinctl (iomuxc) 하는 방식이 TI와 다르게 사용되며, 관련부분은 별도로 봐야한다.

$ cat arch/arm/boot/dts/imx6ull-pinfunc.h  // 핀확인 IOMUXC Register 확인 (Kernel 소스)
$ vi arch/arm/boot/dts/imx6ul*   //

&iomuxc {
...
    pinctrl_can_int: canintgrp {
        fsl,pins = < 
            /*
               IOMUXC_SW_MUX_CTL_PAD : MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04
               IOMUXC_SW_PAD_CTL_PAD : 0x13010   (세부설정가능 Open Drain / Pull / Hysteresis Enable)
                                     : 0x80000000  상위 설정과 다르게 PAD Register를 변경을 막는다고 하는데, bit31/30은 자세한내용은 커널문서 
             */
            MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04    0x13010      /* SODIMM 73 */ 
        >;
    };
...
};

/sys/kernel/debug 가 되는 경우 아래와 같이 Pin 설정확인

$ ls /sys/kernel/debug/pinctrl/  // Target Device에서 debug 모드로 연결하여 확인 

$ cat /sys/kernel/debug/pinctrl/pinctrl-handles  // Target Device에서 설정확인 
Requested pin control handlers their pinmux maps:
device: 20e0000.iomuxc current state: default
........

$ cat /sys/kernel/debug/pinctrl/pinctrl-maps     // 관련정보 
$ cat /sys/kernel/debug/pinctrl/20e0000.iomuxc/pingroups


// GPIO 의 경우 sysfs에서 도 사용가능하지만, 직접 device tree의 모듈에 연결이 되어 사용가능하므로 주의
// 이때 아래와 같이 확인한 후 device tree에서 연결된 모듈의 gpio부분을 제거한 후 사용 

$ cat /sys/kernel/debug/gpio  // GPIO 정보 Debug 
..........
 gpio-112 (                    |peri_3v3            ) out hi
 gpio-114 (                    |sysfs               ) out lo
 gpio-116 (                    |sysfs               ) out lo
 gpio-117 (                    |sysfs               ) out lo
 gpio-118 (                    |sysfs               ) out lo
 gpio-119 (                    |sysfs               ) out lo
 gpio-122 (                    |sysfs               ) out lo
 gpio-123 (                    |can-stby            ) out hi
 gpio-127 (                    |sysfs               ) out lo

최근에 찾은 자료이며, i.MX6의 Device Tree 구조를 아래 사이트에서 쉽게 볼수 있어 업데이트한다.

• i.MX의 Device Tree

i.MX6 관련내용 

  http://developer.toradex.com/device-tree-customization
  https://developer.toradex.com/device-tree-customization#2-imx-6ull-based-modules

/sys/kernel/debug 관련내용
  https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch09s07.html

2. Device Tree 의 수정 및 사용법

Device Tree를 이해한다고, ARM BOOT를 다시 전체 분석을 할 필요는 없다.
지금 현재 제대로 동작을 하고 있으며, 필요한 모듈과 그기능을 찾아 그 부분만 수정을 하면 되기에 dts 파일과 dtsi파일을 이해하고 수정을 하면 되겠다.

2.1  DTS와 각 Driver의 구조 (AM437x 인 경우)

DTS파일과 각 Driver의 기본구조는 다음과 같다.
device tree의 기본동작 방식은 dts파일 안의 compatible의 이름과 driver의 맞을 경우 그 해당하는 driver에게 맞게 동작하게 되어있다.


그러므로, Kernel을 빌드후 다음과 같이 dts의 compatible의 이름을 검색하여 찾아 수정을하면 된다.

Device Tree의 위치는 위에서 설명했듯이 arch/arm/boot/dts/ 보면될 것이지만,관련된 부분을 전부 검색을 해보자.

• Device Tree Source 관련소스 (driver) 검색  

1. Kernel을 빌드 후, find들 이용하여 *.o file list 생성된다. 
2. 이 file list들을 *.o에서 *.c 변경한다.
3. 빌드된 file list의 *.c  중심으로 dts파일의 'compatible'로 검색진행 

$ cd kernel source 
$ find . -name '*.o' | sed -e 's/o$/c/g' | xargs grep -rs 'ti,am4372'
$ find . -name '*.o' | sed -e 's/o$/c/g' | xargs grep -rs 'arm,coretex-a9-gic'
$ find . -name '*.o' | sed -e 's/o$/c/g' | xargs grep -rs 'syscon'

or 

$ MY_KERENL=./kernel_source 
$ find $MY_KERENL -name '*.o' | sed -e 's/o$/c/g' | xargs grep -rs 'syscon' $MY_KERENL

2.2 DTS파일 수정 및 추가방법 (AM437x 경우)  

상위에서 DTS파일을 수정하고, 추가한다면, Kernel 내부의 Makefile 수정하면된다.

DTS파일을 빌드를 원한다면, Kernel로 이동 후에 빌드를 하자.

• AM437x는 기본 Makefile 구성 (DTS관련부분만)

1. Main Makefile ( U-BOOT , Kernel, Filesystem 모두 관리)
2. Rule.make     ( 관련 설정)
3. Kernel Source 내부 Makefile 

• Main Makefile (DTB File Build 수정) 

현재 dtb 파일은 3개만 빌드를하게 만들었으며, 본인이 추가한다면 이곳에서 수정하자

$ vi Makefile
linux: linux-dtbs        ### linux kernel 부분 build 
        @echo =================================
        @echo     Building the Linux Kernel
        @echo =================================
        $(MAKE) -C $(LINUXKERNEL_INSTALL_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) $(DEFCONFIG)
        $(MAKE) -j $(MAKE_JOBS) -C $(LINUXKERNEL_INSTALL_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) zImage
        $(MAKE) -j $(MAKE_JOBS) -C $(LINUXKERNEL_INSTALL_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) modules
.....
# Kernel DTB build targets
linux-dtbs:
        @echo =====================================
        @echo     Building the Linux Kernel DTBs
        @echo =====================================
        $(MAKE) -C $(LINUXKERNEL_INSTALL_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) $(DEFCONFIG)
        $(MAKE) -j $(MAKE_JOBS) -C $(LINUXKERNEL_INSTALL_DIR) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) am43x-epos-evm.dtb am437x-gp-evm.dtb am437x-sk-evm.dtb

• Linux Kernel/Uboot 에서 상위 dtb 생성확인 (check DTB files)

$ cd board-support/linux*  // Linux Kernel Source 이동 

$ find . -name *dtb    // 상위 Makefile로 인하여 dtb 파일은 이미 3개 생성됨 확인  
./arch/arm/boot/dts/am437x-sk-evm.dtb
./arch/arm/boot/dts/am43x-epos-evm.dtb
./arch/arm/boot/dts/am437x-gp-evm.dtb
./include/config/arm/atag/dtb

• Linux Kernel/Uboot 에서 내부 Makefile 수정 (for new DTS File)

상위 Makefile에서 3개만 빌드했기 때문에, 3개이며, 추가를 원한다면 상위 Makefile 수정하자.
새로운 dtb/dts을 추가한다고 하면 Kernel 내부의 dts 관련 Makefile 파일을 수정하자.

$ cd board-support/linux*  // Linux Kernel Source 이동 

$ vi .config  // Kernel Config 확인 
...
CONFIG_SOC_AM43XX=y
# CONFIG_SOC_DRA7XX is not set
CONFIG_ARCH_OMAP2PLUS=y
....

$ vi arch/arm/boot/dts/Makefile   // new dts file 추가 , 본인의 dts 설정파일 만들어 추가하자

dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
        omap2430-sdp.dtb \
        omap2420-n800.dtb \
        omap2420-n810.dtb \
        omap2420-n810-wimax.dtb \
        omap3430-sdp.dtb \
        omap3-beagle.dtb \
        omap3-cm-t3730.dtb \
        omap3-sbc-t3730.dtb \
        omap3-devkit8000.dtb \
        omap3-beagle-xm.dtb \
        omap3-evm.dtb \
        omap3-evm-37xx.dtb \
        omap3-ldp.dtb \
        omap3-n900.dtb \
        omap3-n9.dtb \
        omap3-n950.dtb \
        omap3-overo-tobi.dtb \
        omap3-overo-storm-tobi.dtb \
        omap3-gta04.dtb \
        omap3-igep0020.dtb \
        omap3-igep0030.dtb \
        omap3-zoom3.dtb \
        omap4-panda.dtb \
        omap4-panda-a4.dtb \
        omap4-panda-es.dtb \
        omap4-var-som.dtb \
        omap4-sdp.dtb \
        omap4-sdp-es23plus.dtb \
        omap5-uevm.dtb \
        am335x-evm.dtb \
        am335x-evmsk.dtb \
        am335x-bone.dtb \
        am335x-boneblack.dtb \
        am335x-nano.dtb \
        am335x-base0033.dtb \
        am3517-craneboard.dtb \
        am3517-evm.dtb \
        am3517_mt_ventoux.dtb \
        am43x-epos-evm.dtb \
        am43x-epos-evm-hdmi.dtb \
        am437x-gp-evm.dtb \
        am437x-gp-evm-hdmi.dtb \
        am437x-sk-evm.dtb \
        dra7-evm.dtb \
        dra7-evm-lcd10.dtb \
        dra72-evm.dtb \
        dra72-evm-lcd10.dtb \
        am57xx-beagle-x15.dtb \
        am57xx-evm.dtb

• Linux Kernel 내부 Makefile 에서 zImage 확인 

 zImage 빌드 할 경우 정확한 설정 확인하고, dtb와 연관성을 확인하자.
 아래의 *.cmd는 실행한 결과들이며, 이것을 확인을 하면, 어떻게 생성이 되었는지 쉽게  이해를 할수 있다.

$ cd board-support/linux*  // Linux Kernel Source 이동 

$ find . -name zImage   //zImage 와 Image 위치파악  
./arch/arm/boot/zImage

$ ls -a arch/arm/boot/    // zImage와 Image 생성 부분 분석 ( Makefile , *.cmd) 
.  ..  .Image.cmd  .gitignore  .zImage.cmd  Image  Makefile  bootp  compressed  dts  install.sh  zImage

$ cat ./arch/arm/boot/.zImage.cmd   //제대로 빌드되었다면 아래와 같이 확인가능 
cmd_arch/arm/boot/zImage := /home/jhlee/am437x/works/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-objcopy -O binary -R .comment -S  arch/arm/boot/compressed/vmlinux arch/arm/boot/zImage

$ vi arch/arm/boot/Makefile  // zImage 확인 
....
targets := Image zImage xipImage bootpImage uImage

ifeq ($(CONFIG_XIP_KERNEL),y)        // 현재 XIP 모드가 아님 ( NOR NAMD 이면, 가능하겠지만?)

$(obj)/xipImage: vmlinux FORCE
        $(call if_changed,objcopy)
        @$(kecho) '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'

$(obj)/Image $(obj)/zImage: FORCE
        @echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
        @echo 'Only the xipImage target is available in this case'
        @false

else

$(obj)/xipImage: FORCE
        @echo 'Kernel not configured for XIP (CONFIG_XIP_KERNEL!=y)'
        @false

$(obj)/Image: vmlinux FORCE
        $(call if_changed,objcopy)
        @$(kecho) '  Kernel: $@ is ready'

$(obj)/compressed/vmlinux: $(obj)/Image FORCE
        $(Q)$(MAKE) $(build)=$(obj)/compressed $@

$(obj)/zImage:  $(obj)/compressed/vmlinux FORCE
        $(call if_changed,objcopy)                 ## OBJCOPYFLAGS 사용하며, objcopy를 이용하여 object를 binary를 만들때 사용한다  
        @$(kecho) '  Kernel: $@ is ready'          ## 자세한 내용은 Kernel 문서와 GCC 참조 

endif

• Filesytem 에서 DTB와 Kernel zImage 확인 

Partition 과 Booting 부분에 있어, Partition은 2개이며, (fat32 와 filesystem 으로 존재) uboot는 fat32에 존재하며, 설정값도 그곳에 존재한다.
그리고 Filesystem 안의 boot에는  dtb 파일과 zImage는 File 형태로 존재하며 아래의 NFS File system에서도 동일하다.

$ cd board-support/linux*  // Linux Kernel Source 이동 
$ sudo cp arch/arm/boot/zImage /boot   // File System의 Boot에 저장 
$ sudo cp arch/arm/boot/dts/
.dtb /boot // File System의 Boot에 저장

$ targetNFS/boot  //Kernel Image 와 *.dtb File 확인 (File system 안에 존재)
$ ll
drwxr-xr-x  2 jhlee jhlee      4096  7월  7  2015 ./
drwxr-xr-x 21 jhlee jhlee      4096  7월  7  2015 ../
lrwxrwxrwx  1 jhlee jhlee        40  7월  7  2015 am437x-gp-evm-hdmi.dtb -> devicetree-zImage-am437x-gp-evm-hdmi.dtb
lrwxrwxrwx  1 jhlee jhlee        35  7월  7  2015 am437x-gp-evm.dtb -> devicetree-zImage-am437x-gp-evm.dtb
lrwxrwxrwx  1 jhlee jhlee        35  7월  7  2015 am437x-sk-evm.dtb -> devicetree-zImage-am437x-sk-evm.dtb
lrwxrwxrwx  1 jhlee jhlee        41  7월  7  2015 am43x-epos-evm-hdmi.dtb -> devicetree-zImage-am43x-epos-evm-hdmi.dtb
lrwxrwxrwx  1 jhlee jhlee        36  7월  7  2015 am43x-epos-evm.dtb -> devicetree-zImage-am43x-epos-evm.dtb
-rw-r--r--  1 jhlee jhlee     49048  7월  7  2015 devicetree-zImage-am437x-gp-evm-hdmi.dtb
-rw-r--r--  1 jhlee jhlee     48112  7월  7  2015 devicetree-zImage-am437x-gp-evm.dtb
-rw-r--r--  1 jhlee jhlee     42675  7월  7  2015 devicetree-zImage-am437x-sk-evm.dtb
-rw-r--r--  1 jhlee jhlee     48544  7월  7  2015 devicetree-zImage-am43x-epos-evm-hdmi.dtb
-rw-r--r--  1 jhlee jhlee     47461  7월  7  2015 devicetree-zImage-am43x-epos-evm.dtb
-rw-r--r--  1 jhlee jhlee 105402448  7월  7  2015 vmlinux-3.14.43-g875c69b
lrwxrwxrwx  1 jhlee jhlee        23  7월  7  2015 zImage -> zImage-3.14.43-g875c69b
-rw-r--r--  1 jhlee jhlee   4355472  7월  7  2015 zImage-3.14.43-g875c69b

• TI-Kernel User Guide

  많은 부분이 아래에 내용에 나오며 아래부분을 참고하자.

  http://processors.wiki.ti.com/index.php/Linux_Kernel_Users_Guide


3. How To compile DTS Files

위에서 언급했듯이 Kernel에서 직접 DTS를 빌드하고자 한다면, 아래와 같이 빌드하자.
다만 새로 추가했다면, Kernel 내부 Makefile을 수정해야하며, DTS에 맞는 Kernel Config를 확인하자.

$ cd board-support/linux*  // linux kernel 이동  
$ ls .config // DTS에 맞는 config 설정이 되어있어야 함.
$ make ARCH=arm CROSS_COMPILE=arm-xxxxx            
$ make ARCH=arm CROSS_COMPILE=arm-xxxxx am43x-epos-evm.dtb

만약, 위의 Makefile 파일에 추가 및 Makefile Config가 추가 되지 않았다면, target이 추가되지 않아 dtb를 compile를 할수가 없다.


3.1 How To use DTC(Device Tree Compiler)

위와 같이 Kernel Makefile를 이용하여 빌드하는 방법도 있지만,
직접 dtc를 사용하여 compile 하는 방법도 가능하다

*참고사항:  처음 Kernel source를 받으면, dtc file은 존재하지 않는다. build 도중 생김

• DTC (Device Tree Compiler)

$ cd board-support/linux*  // linux kernel 이동  
$ ./scripts/dtc/dtc -I dtb -O dts -o (devicetree name).dts (devicetree name).dtb  // 직접 build 

  http://www.wiki.xilinx.com/Build+Device+Tree+Blob

4. Device Tree Guide

• Device Tree Syntax Spec (중요)  

** Device Tree의 Spec이 별도 존재하며 지속적으로 Update되고 있으므로, 각 Spec을 반드시 읽고 확인
  https://www.devicetree.org/specifications/ (문법)
  http://devicetree.org/Device_Tree_Usage  (수정방법)

• TI Device Tree 사용법  

  http://omappedia.org/wiki/Device_Tree

• Kernel/Uboot 내부 문서  

** Device Tree 사용 및 방법이 Chip Vendor마다 조금씩 다르므로 반드시 Kernel 문서를 확인해야함
  https://www.kernel.org/doc/Documentation/arm/Booting

• 쉽게 Device Tree를 설명해주는 사이트  

Device Tree를 쉽게 설명해주는 Guide이고, 아래의 문서에서 위의 그림을 복사하여 넣었다.

  http://www.elinux.org/images/a/ad/Arm-soc-checklist.pdf
  http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
  http://schedule2012.rmll.info/IMG/pdf/LSM2012_ArmKernelConsolidation_Petazzoni.pdf
  http://events.linuxfoundation.org/sites/events/files/slides/presentation_3.pdf
  http://lxr.free-electrons.com/source/Documentation/devicetree/booting-without-of.txt

find 검색

1. Find 기본사용법

find는 원하는 file을 찾을 경우 사용하며, file정보를이용하여 검색하기 때문에 grep보다 빠른 검색가능하다.

SYNOPSIS
       find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]

1.1.  Find 의 옵션  

Find는 FILE의 정보기준으로 검색을 하며, 다양한 옵션들을 제공하여 빨리 원하는 FILE들을 찾아준다.

• Find 기본연산옵션

1. FILE의 이름관련 연산
2. FILE의 시간관련 연산 
3. FILE의 사이즈관련 연산
4. AND/OR/NOT 연산제공 :  상위 1/2/3번의 조합이 가능 

**SIZE 관련 연산

       -size n[cwbkMG]
              File uses n units of space.

              `b'    for 512-byte blocks (this is the default if no suffix is used)
              `c'    for bytes
              `w'    for two-byte words
              `k'    for Kilobytes (units of 1024 bytes)
              `M'    for Megabytes (units of 1048576 bytes)
              `G'    for Gigabytes (units of 1073741824 bytes)

**TIME 관련 연산  (time: 기본단위는 24*hours , min:  minutes)

        -mtime  n : modified n days ago         (파일의 내용을 변경시 )
        -mmin   n : modified minutes ago
        -atime  n : access   n days ago         (파일을 오픈했을 경우, cat, vi, grep, head )
        -amin   n : access   minutes ago  
        -ctime  n : changed  n days ago          (파일의  속성이 변경시)
        -cmin   n : changed  minutes ago

**SIZE/TIME의 숫자개념 

         -n  :  for less  than  ( < n )
         +n  :  for great than  ( > n )
          n  :  for exactly n   (  n )

상위 FILE의 SIZE 및 TIME 연산의 AND/OR/NOT 연산가능

**AND OR 연산 및 NOT 연산 

       -not expr
              Same as ! expr, but not POSIX compliant.

       expr1 expr2
              Two expressions in a row are taken to be joined with an implied "and"; expr2 is not evaluated if expr1 is false.

       expr1 -a expr2
              Same as expr1 expr2.

       expr1 -and expr2
              Same as expr1 expr2, but not POSIX compliant.

       expr1 -o expr2
              Or; expr2 is not evaluated if expr1 is true.

       expr1 -or expr2
              Same as expr1 -o expr2, but not POSIX compliant.

       expr1 , expr2
              List;

• Find의 기타옵션 

1. 다른 command 실행연산
2. FILE 검색결과의 출력방법

**실행연산

       -exec command ;

**output 종류 

newline을 사용여부 및 프로그래밍으로 output을 만들수 있다 이 부분 man을 참고

       -print0
              True; print the full file name on the standard output, followed by a null character

       -print True; print the full file name on the standard output, followed by a newline.

       -printf format
              True;  print  format  on  the standard output,

              %p     File's name.

              %P     File's name with the name of the command line argument under which it was found removed.

              %s     File's size in bytes.

              %b     The amount of disk space used for this file in 512-byte blocks.

              %k     The amount of disk space used for this file in 1K blocks.

2. Find 예제 


2.1 FILE의 이름기준 검색 


* : 여러글자 대체
? : 한글자만 대체
[1-8] : 한글자만 정의 (1~8)
[a-c] : 한글자만 정의 (a~c)

$ find . -name  expr// 원하는 검색어 
$ find . -name '*.o'   // *.o 파일 검색  (가능하면 '' or ""사용) 
$ find . -name *.h    // *.h  파일 검색
$ find . -name *droid-[2-5]*  // android-2/4/5 검색
$ find . -name *droid-[2-5].[0-1]*  //e.g android-2.0 검색
$ find ./ -name '*aic*.o' // 중간에 aic 파일 검색

2.2 FILE의 시간기준 검색 

시간은 모두 과거의 기준으로 검색을 하기에 +- 모두 과거시간들과 검색한다.
다만 차이가 있다면 아래와 같이 n 에따라 -:less than or +:great than or 일치 있을 뿐이다.

$ find . -mtime -7             // 수정날짜 (n < 7   ) 현재 FILE(0) ~ 7일전 FILE 검색  
$ find . -mmin  30             // 수정시간 ( n         ) 오직 30분전 변경된 FILE 만 검색 
$ find . -mmin  -30            // 수정시간 ( n < 30 ) 현재 FILE(0) ~ 30분전 FILE 검색  
$ find . -mmin  +30            // 수정시간 ( n > 30 ) 30분전 FILE  ~ 이전전부 FILE 검색       
$ find . -mmin +30 -mmin -60   // 수정시간 (30 >n , n < 60) 30분전 ~ 60분전 사이만 검색 (AND연산) 

$ find . -atime n/-n/+n        // 액세스 날짜 (파일오픈) 
$ find . -amin n/-n/+n         // 액세스 시간 

$ find . -ctime n/-n/+n        // 파일속성변경 날짜 (파일오픈 및 사용) 
$ find . -cmin n/-n/+n         // 파일속성변경 시간 

2.3 FILE의 크기기준검색

FILE의 시간과 동일하게 적용하면됨

$ find ./ -size  +50k
$ find ./ -size  +50k -printf "%p            %s\n"    // printf format을 만들어 사용 자세한 내용은 man참고 
$ find ./ -size  +50k | xargs du -hs
$ find ./ -size  +50k | xargs du -h

2.4 연산의 AND/OR/NOT 검색

$ find ./ -name 'snd-*.o' -o -name 'snd*.h'   // NAME 연산 NAME 연산  OR연산 적용 
$ find ./ -name 'snd-soc*.o' -a -name 'snd*.o'   // NAME 연산 NAME 연산 AND 연산적용  
$ find ./sound/  -name '*.o' -not -name 'built-in.o' //NAME 연산 NAME 연산 NOT 연산적용  ( *.o 검색 하고, -not으로 제외) 
$ find . -mtime -7  -name '*.c' -o -name '*.h'   // 7일전- 현재    수정한 파일 중 *.c or *.h 검색 
$ find . -mmin -60 -name '*.c' -o -name '*.h'   // 60분전 - 현재   수정한 파일 중 *.c or *.h 검색

• 수정시간 과 파일이름 검색이용 예제

$ find . -mtime -7  -name '*.c' -o -name '*.h'   // 7일전- 현재    수정한 파일 중 *.c or *.h 검색 
$ find . -mmin -60 -name '*.c' -o -name '*.h'   // 60분전 - 현재   수정한 파일 중 *.c or *.h 검색 

• 수정시간 현재부터 30일 이전까지 관련 내용 검색  ( 30 < n )

$ find . -mtime -30 -name '*.c' -o -name '*.h' // 검색내용 중  *.c 혹은 *.h 검색 
$ find . -mtime -30 -name '*.h'                // 검색내용 중  *.h 만 재검색

• 30이전 부터 60이전까지 관련내용 검색 (  30 > n  &&  60  < n )

$ find . -mtime +30 -mtime -60  -name '*.c' -o -name '*.h'
$ find . -mtime +30 -mtime -60  -name '*.h' 

• find를 이용한 내부 command 이용 

 아래 내용은 날짜별로 관련내용을 분류할때 사용. (mv를 실행)
       - '{}' ';'     find 내부 command

$ find . -name "*.VER" -mtime -31 -exec mv '{}' /opt/html/31';' -print
$ find . -name "*.VER" -mtime +31 -mtime -62 -exec mv '{}' /opt/html/62 ';' -print

  http://www.linux-faqs.info/general/difference-between-mtime-ctime-and-atime

Raspberry Pi3 에 Yocto 와 Qt 적용한 Image (정리못함)

1. Raspberry Pi 와 Qt5 관련정보사항 

Yocto 기본 사용 
  https://ahyuo79.blogspot.com/2015/10/yocto.html
  https://ahyuo79.blogspot.com/2015/10/imx6.html

Yocto 기본문법 과 정리 (필독)
  https://ahyuo79.blogspot.com/2020/01/raspberry-pi3-linux-yocto.html

Yocto Recipe 작성방법 

  https://ahyuo79.blogspot.com/2020/02/yocto-recipe.html

이전 Raspberry Pi Yocto 구성 
  https://ahyuo79.blogspot.com/2018/02/raspberry-pi-systems-with-yoctohtml.html

기본적으로 Raspberry Pi 기반으로 나만의 Qt를 이용하여 나만의 Yocto로 구성하고자하는 마음으로 이것을 시작했다. 

• Raspberry Pi용 Image 생성 (Yocto 기반)

Raspberry Pi에 적용할 Yocto 기반으로 구성된 Qt를 포함 Image를 생성하는 방법 

1. 이미 구성된 Yocto Layer들과 Recipe들을 직접 Download 
2. Yocto의 각 Layer들 별로 Download 후 별도의 Image Recipe를 구성하여 빌드 

간단하게만 Build 테스트 만 했지만, 실제로 Image를 Write해서 다 확인하지는 않았으며, 틀린부분은 추후 시간이 있을 때 수정하여 보완하도록 하자.

• 상위 진행결과   

완벽히는 구성을 못했지만, Qt기반으로 실행가능한 정도로만 구성하여 동작확인을 하였다. 

아래와 같이 Laptop이 아래와 같이 Ubuntu Laptop 지워져서 정리 포기함  

  https://ahyuo79.blogspot.com/2022/06/lenova-laptop-ubuntu.html

상위 부분은 앞으로 진행못할 거 같으며, 추후 기회가 있다면 그때 다시 하도록 하자. 

그리고, 아래의 내용은 이전에 정리해둔 것이므로 나중에 참조만 하도록하자.

이후 변경된 내용은 백업을 못한 내 잘못이 더 크다. 

그리고, 칩제조사 TI/NXP에서 제공하는 Yocto가 아닌 Poky 와 OpenEmbedded 기반으로 간단하게 구성하여 누구나 할 수 있다. 

1.1  이미 구성된 Yocto 기반으로 Image 생성 

Yocto를 별도로 구성할 필요 없이 repo를 이용하여 Yocto를 전체 Layer들을 직접 Download 한 후 Manual 대로 설정 한 후 bitbake로 실행하여 Image 생성 

QT 관련설치
  https://doc.qt.io/QtForDeviceCreation/qtee-custom-embedded-linux-image.html
  https://code.qt.io/cgit/yocto/boot2qt-manifest.git/tree/

• 기존에 존재하는 Yocto (QT 테스트)

아래와 같이 처음 Qt 테스트 진행 

$ sudo apt-get install gawk curl git-core git-lfs diffstat unzip texinfo build-essential \
chrpath libsdl1.2-dev xterm gperf bison gcc-multilib g++-multilib repo

$ cd rasp-qt

$ repo init -u git://code.qt.io/yocto/boot2qt-manifest -m warrior.xml  // ok

$ repo init -u git://code.qt.io/yocto/boot2qt-manifest -m zeus.xml // not work 

$ repo sync

$ MACHINE=raspberrypi3 source ./setup-environment.sh

$ bitbake b2qt-embedded-qt5-image

$ bitbake meta-toolchain-b2qt-embedded-qt5-sdk

2. Yocto 의 Layer를 직접 구성 후 Image 생성 

본인이 Yocto의 Main인 Poky 부터 필요한 Layer들을 각 모아서 구성한 후, 필요한 Image recipe 역시 직접 만들어서 구성한 후, 

이 기반으로 최종 Raspberry Pi Image 생성 

• 이전에 구성한 Raspberry Pi Yocto 

  https://ahyuo79.blogspot.com/2018/02/raspberry-pi-systems-with-yoctohtml.html

• Yocto에서 먼저확인 해봐야할 것

Yocto의 Version 정보와 Dependencies 이 될 것 같다. 
항상 최신버전만을 받았지만, 이번에는 다양한 Version을 받아보기 위해서 일단 아래에서 branch 정보를 파악해서 원하는 것으로 받기로 했다.

• QT 설치방법 

현재 Image가 안되며, layer를 추가한 후 아래 medium을 똑같이 해보자
  https://makersweb.net/embedded/12540
  https://medium.com/@shigmas/yocto-pi-and-qt-e9f2df38a610
  https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html

• Yocto Version(Branch) 정보확인 

Yocto에 Version에 부여된 이름이 각각 존재 (zeus로 version(branch) 결정)

• 본인 설치할 Layer 선택

1. ref -> Branch 및 Tag  확인 
2. about->Dependencies 확인 

  http://git.yoctoproject.org/cgit.cgi/
  https://www.yoctoproject.org/software-overview/layers/
  http://layers.openembedded.org/layerindex/branch/master/layers/

• meta-raspberrypi 의 branch 파악

Yocto version: zeus 파악
  http://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/refs/
  https://js94.tistory.com/entry/Yocto-Project-Reference-manual-chap3-35

• Yocto 의 Layer를 각 구성 방법  

1. 상위와는 다르게 각각의 Layer들을 별도로 다운받아 본인 직접구성 (poky, openembedded)
2. 별도의 Layer들을 추가하는 방식으로 구성
3. 추후 더 필요하다면 확장하는 방식으로 구성 

$ mkdir -p works/raspberrypi/sources

$ cd works/raspberrypi/source

$ pwd
/home/jhlee/works/raspberrypi/sources

$ git clone -b zeus  git://git.yoctoproject.org/poky
$ git clone -b zeus  git://git.openembedded.org/meta-openembedded
$ git clone -b zeus  https://github.com/agherzan/meta-raspberrypi
$ git clone -b zeus  git://github.com/meta-qt5/meta-qt5.git       // 처음에 못찾다가 상위 Layer에서 찾음 

Machine/Distro Layer 구성의 예 

  https://ahyuo79.blogspot.com/2020/02/yocto-layer-configuration.html

• 기본구성 후 conf/machine 확인 

우선 machine Layer 의 설정을 알기 위해서 검색 

물론 QEMU도 확인가능 

$ find . -name machine | xargs ls   // conf/machine 관련된 부분 전부 검색 
./meta-raspberrypi/conf/machine:
include     raspberrypi0-wifi.conf  raspberrypi3-64.conf  raspberrypi4-64.conf  raspberrypi-cm3.conf  raspberrypi.conf
raspberrypi0.conf  raspberrypi2.conf    raspberrypi3.conf  raspberrypi4.conf     raspberrypi-cm.conf

./poky/meta/conf/machine:
include  qemuarm.conf qemumips64.conf  qemuppc.conf    qemux86-64.conf
qemuarm64.conf qemuarmv5.conf qemumips.conf  qemuriscv64.conf  qemux86.conf

./poky/meta-selftest/conf/machine:
qemux86copy.conf

./poky/meta-yocto-bsp/conf/machine:
beaglebone-yocto.conf  edgerouter.conf genericx86-64.conf  genericx86.conf  include  mpc8315e-rdb.conf 

MACHINE 설정부터 BBLAYERS 확인  

$ find . -name local.conf*  // conf/local.conf 부분 검색 
./poky/meta-poky/conf/local.conf.sample
./poky/meta-poky/conf/local.conf.sample.extended


$ vi ./poky/meta-poky/conf/local.conf.sample  // 추후 build에 이 파일 기준으로 적용됨 
....
MACHINE ?= "raspberrypi3-64"
# This sets the default machine to be qemux86-64 if no other machine is selected:
#MACHINE ??= "qemux86-64"


$ vi ./poky/meta-poky/conf/bblayers.conf.sample // 추후 build에 이 파일 기준으로 적용됨, Build 설정 이후로 수정하기로 결정  

BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-poky \
  ##OEROOT##/meta-yocto-bsp \
  "

• 현재 구성된 Yocto 구성도 

$ pwd
/home/jhlee/works/raspberrypi/sources

$ tree -t -L 2   // Yocto 전체 Layer와 각 구성확인 
.
├── meta-openembedded
│   ├── contrib
│   ├── COPYING.MIT
│   ├── meta-filesystems
│   ├── meta-gnome
│   ├── meta-initramfs
│   ├── meta-multimedia
│   ├── meta-networking
│   ├── meta-oe
│   ├── meta-perl
│   ├── meta-python
│   ├── meta-webserver
│   ├── meta-xfce
│   └── README
├── meta-raspberrypi
│   ├── classes
│   ├── conf
│   ├── COPYING.MIT
│   ├── docs
│   ├── dynamic-layers
│   ├── files
│   ├── README.md
│   ├── recipes-bsp
│   ├── recipes-connectivity
│   ├── recipes-core
│   ├── recipes-devtools
│   ├── recipes-graphics
│   ├── recipes-kernel
│   ├── recipes-multimedia
│   └── wic
├── poky
│   ├── bitbake
│   ├── contrib
│   ├── documentation
│   ├── LICENSE
│   ├── LICENSE.GPL-2.0-only
│   ├── LICENSE.MIT
│   ├── meta
│   ├── meta-poky
│   ├── meta-selftest
│   ├── meta-skeleton
│   ├── meta-yocto-bsp
│   ├── oe-init-build-env
│   ├── README.hardware -> meta-yocto-bsp/README.hardware
│   ├── README.OE-Core
│   ├── README.poky -> meta-poky/README.poky
│   ├── README.qemu
│   └── scripts
└── meta-qt5
    ├── classes
    ├── conf
    ├── COPYING.MIT
    ├── files
    ├── lib
    ├── licenses
    ├── README.md
    ├── recipes-connectivity
    ├── recipes-devtools
    ├── recipes-multimedia
    ├── recipes-python
    └── recipes-qt

• Build 환경구성 

기본 Build 환경구성 확인 과 Build 

$ cd ..

$ pwd
/home/jhlee/works/raspberrypi

$ source sources/poky/oe-init-build-env rpi-build  // Yocto Poky 기반으로 Build 환경설정 
or
$ . sources/poky/oe-init-build-env rpi-build

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'


Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package task

$ pwd
/home/jhlee/works/raspberrypi/rpi-build

• Build 환경구성 확장  

BBLAYERS에 추가된 Layer들을 추가하여 확장하여 이를 확장 

$ cd .. 

$ pwd
/home/jhlee/works/raspberrypi

$ tree -t -L 2  // Yocto 전체 Layer 와 Build 관련부분 파악 
.
├── sources
│   ├── meta-openembedded
│   ├── meta-raspberrypi
│   ├── meta-qt5
│   └── poky
└── rpi-build
    └── conf

$ cd ./rpi-build  // Build 환경으로 다시  

$ JHLEE=$HOME/works/raspberrypi/sources

$ echo $JHLEE
/home/jhlee/raspberrypi/sources

$ cat conf/bblayers.conf 
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/jhlee/works/raspberrypi/sources/poky/meta \
  /home/jhlee/works/raspberrypi/sources/poky/meta-poky \
  /home/jhlee/works/raspberrypi/sources/poky/meta-yocto-bsp \
  "

//meta-raspberrypi 필요한 Layer들 별도로 추가 (dependecies)
$ echo "BBLAYERS += \"$JHLEE/meta-openembedded/meta-oe\"" >> conf/bblayers.conf
$ echo "BBLAYERS += \"$JHLEE/meta-openembedded/meta-multimedia\"" >> conf/bblayers.conf
$ echo "BBLAYERS += \"$JHLEE/meta-openembedded/meta-networking\"" >> conf/bblayers.conf
$ echo "BBLAYERS += \"$JHLEE/meta-openembedded/meta-python\"" >> conf/bblayers.conf

$ echo "BBLAYERS += \"$JHLEE/meta-raspberrypi\"" >> conf/bblayers.conf
$ echo "BBLAYERS += \"$JHLEE/meta-qt5\"" >> conf/bblayers.conf

$ cat conf/bblayers.conf    // 최종 bitbake Layer 관련설정 확인  
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/jhlee/works/raspberrypi/sources/poky/meta \
  /home/jhlee/works/raspberrypi/sources/poky/meta-poky \
  /home/jhlee/works/raspberrypi/sources/poky/meta-yocto-bsp \
  "
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-oe"
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-multimedia"
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-networking"
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-python"
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-raspberrypi"
BBLAYERS += "/home/jhlee/works/raspberrypi/sources/meta-qt5"

// priority 의 경우 어떻게 측정되는 지 추후 더 파악 (만약 Package가 제대로 설치되어있지 않으면 실행이 안됨) 
$ bitbake-layers show-layers  
NOTE: Starting bitbake server...
layer                 path                                      priority
==========================================================================
meta                  /home/jhlee/works/raspberrypi/sources/poky/meta  5
meta-poky             /home/jhlee/works/raspberrypi/sources/poky/meta-poky  5
meta-yocto-bsp        /home/jhlee/works/raspberrypi/sources/poky/meta-yocto-bsp  5
meta-oe               /home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-oe  6
meta-multimedia       /home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-multimedia  6
meta-networking       /home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-networking  5
meta-python           /home/jhlee/works/raspberrypi/sources/meta-openembedded/meta-python  7
meta-raspberrypi      /home/jhlee/works/raspberrypi/sources/meta-raspberrypi  9
meta-qt5              /home/jhlee/works/raspberrypi/sources/meta-qt5  7

• 전체 Image Recipe 찾기 

현재 사용중인 Image Recipe를 찾아 역으로 분석하여 기본구조를 파악하자 

$ find ../sources -name *image*.bb   // bitbake 의 image bb recipe 파일 전부 검색  
../sources/meta-openembedded/meta-filesystems/recipes-filesystems/images/meta-filesystems-image-base.bb
../sources/meta-openembedded/meta-filesystems/recipes-filesystems/images/meta-filesystems-image.bb
../sources/meta-openembedded/meta-webserver/recipes-core/images/meta-webserver-image-base.bb
../sources/meta-openembedded/meta-webserver/recipes-core/images/meta-webserver-image.bb
../sources/meta-openembedded/meta-multimedia/recipes-multimedia/images/meta-multimedia-image-base.bb
../sources/meta-openembedded/meta-multimedia/recipes-multimedia/images/meta-multimedia-image.bb
../sources/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-debug-image.bb
../sources/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb
../sources/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-image.bb
../sources/meta-openembedded/meta-initramfs/recipes-core/images/meta-initramfs-image.bb
../sources/meta-openembedded/meta-networking/recipes-core/images/meta-networking-image.bb
../sources/meta-openembedded/meta-networking/recipes-core/images/meta-networking-image-base.bb
../sources/meta-openembedded/meta-xfce/recipes-core/images/core-image-minimal-xfce.bb
../sources/meta-openembedded/meta-python/recipes-core/images/meta-python-image-base.bb
../sources/meta-openembedded/meta-python/recipes-core/images/meta-python-ptest-image.bb
../sources/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb
../sources/meta-openembedded/meta-oe/recipes-core/images/meta-oe-image-base.bb
../sources/meta-openembedded/meta-oe/recipes-core/images/meta-oe-ptest-image.bb
../sources/meta-openembedded/meta-oe/recipes-core/images/meta-oe-image.bb
../sources/meta-openembedded/meta-oe/recipes-graphics/libsdl/libsdl-image_1.2.12.bb
../sources/meta-openembedded/meta-oe/recipes-graphics/libsdl/libsdl2-image_2.0.3.bb
../sources/meta-openembedded/meta-oe/recipes-support/imagemagick/imagemagick_7.0.8.bb
../sources/meta-openembedded/meta-perl/recipes-perl/images/meta-perl-ptest-image.bb
../sources/meta-openembedded/meta-perl/recipes-perl/images/meta-perl-image.bb
../sources/meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb
../sources/meta-raspberrypi/recipes-core/images/rpi-basic-image.bb
../sources/meta-raspberrypi/recipes-core/images/rpi-test-image.bb
../sources/poky/meta-skeleton/recipes-multilib/images/core-image-multilib-example.bb
../sources/poky/meta-selftest/recipes-test/container-image/container-image-testpkg.bb
../sources/poky/meta-selftest/recipes-test/container-image/container-test-image.bb
../sources/poky/meta-selftest/recipes-test/images/wic-image-minimal.bb
../sources/poky/meta-selftest/recipes-test/images/test-empty-image.bb
../sources/poky/meta-selftest/recipes-test/images/error-image.bb
../sources/poky/meta-selftest/recipes-test/images/oe-selftest-image.bb
../sources/poky/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
../sources/poky/meta/recipes-extended/images/core-image-kernel-dev.bb
../sources/poky/meta/recipes-extended/images/core-image-testmaster.bb
../sources/poky/meta/recipes-extended/images/core-image-full-cmdline.bb
../sources/poky/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
../sources/poky/meta/recipes-rt/images/core-image-rt.bb
../sources/poky/meta/recipes-rt/images/core-image-rt-sdk.bb
../sources/poky/meta/recipes-core/images/core-image-minimal.bb
../sources/poky/meta/recipes-core/images/core-image-tiny-initramfs.bb
../sources/poky/meta/recipes-core/images/core-image-minimal-dev.bb
../sources/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb
../sources/poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb
../sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb
../sources/poky/meta/recipes-core/images/core-image-base.bb
../sources/poky/meta/recipes-core/ovmf/ovmf-shell-image.bb
../sources/poky/meta/recipes-sato/images/core-image-sato-dev.bb
../sources/poky/meta/recipes-sato/images/core-image-sato-ptest-fast.bb
../sources/poky/meta/recipes-sato/images/core-image-sato-sdk.bb
../sources/poky/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
../sources/poky/meta/recipes-sato/images/core-image-sato.bb
../sources/poky/meta/recipes-graphics/images/core-image-weston.bb
../sources/poky/meta/recipes-graphics/images/core-image-clutter.bb
../sources/poky/meta/recipes-graphics/images/core-image-x11.bb
../sources/poky/meta/recipes-graphics/xorg-lib/xcb-util-image_0.4.0.bb
../sources/meta-qt5/recipes-qt/qt5/qtimageformats_git.bb

$ cd ../sources/meta-qt5
$ mkdir -p recipes-core/images
$ cd recipes-core/images

$ vi core-image-qt5.bb     // Qt기반으로 Image Recipe 파일 직접구성 (기본은 core-image-base) 
$ cat core-image-qt5.bb 
SUMMARY = "Qt5 image that fully supports the target device hardware."
LICENSE="MIT"

include recipe-core/images/core-image-base.bb

QT_BASE = " \
    qtbase \
    qtbase-dev \
    qtbase-mkspecs \
    qtbase-plugins \
    qtbase-tools \
"
 
QT_PKGS = " \
    qt3d \
    qt3d-dev \
    qt3d-mkspecs \
    qtcharts \
    qtcharts-dev \
    qtcharts-mkspecs \
    qtconnectivity-dev \
    qtconnectivity-mkspecs \
    qtquickcontrols2 \
    qtquickcontrols2-dev \
    qtquickcontrols2-mkspecs \
    qtdeclarative \
    qtdeclarative-dev \
    qtdeclarative-mkspecs \
    qtgraphicaleffects \
    qtgraphicaleffects-dev \
"

IMAGE_INSTALL += " \
    ${QT_BASE} \
    ${QT_PKGS} \
"

export IMAGE_BASENAME = "core-image-qt5"

$ bitbake core-image-qt5

$ devtool build core-image-qt5 source 

$ bitbake -e |grep IMAGE_FSTYPE

$ find .. -name bitbake.conf
../sources/poky/bitbake/lib/bb/tests/runqueue-tests/conf/bitbake.conf
../sources/poky/meta/conf/bitbake.conf

Build는 되지만, Image가 생성이 안되었으며,  간단하게 따라한 것이니, 추후에 시간이 있을 경우, QT Package 와 함께 

그때 세부적 분석한 후 관련 Recipe들을 수정하여 구성하자. 

너무 대충 구성한 것 같음. 

• 아래는 Image Recipe를 만들때, 너무 좋은 예제인 것 같아, 추후에 참조 

LoRa 작업을 하면서 아래 Recipe를 각각 다 만들었는데,  괜찮게 만든 것 같아 추후에 다시 참조하며, Raspberry Pi3에 넣도록 하자 

Raspberry Pi3 와 LoRa Gateway 검색해보면 관련자료는 많이 나온다. 

LoRa Gateway 와 Packet Forwarder 

  https://github.com/Lora-net/packet_forwarder

  https://github.com/Lora-net/lora_gateway

더불어 QT에도 추후에 추가도 가능하며, 이 부분은 Background로 돌리수도 있다. 

$ vi ../sources/meta-lora-net/recipes-core/images/core-lora-image.bb
SUMMARY = "Lora Gateway Image dev image"

include recipes-core/images/core-image-base.bb

IMAGE_INSTALL += "lora-gateway lora-pkt-fwd"

export IMAGE_BASENAME = "core-lora-image"

my_postprocess_function() {
   echo "hello" > ${IMAGE_ROOTFS}/hello.txt
}

ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "

$ sample ROOTFS_POSTPROCESS_COMMAND
#
# Copyright (C) 2010 Intel Corporation.
#
require recipes-core/images/poky-image-minimal.bb

SRC_URI = "file://interfaces"

IMAGE_INSTALL += "dropbear mediatomb task-poky-nfs-server"

LICENSE = "MIT"

ROOTFS_POSTPROCESS_COMMAND += "setup_target_image ; "

# Manual workaround for lack of auto eth0 (see bug #875)
setup_target_image() {
       install -m 0644 ${WORKDIR}/interfaces ${IMAGE_ROOTFS}/etc/network/interfaces
}

$ gateway.bb

SUMMARY = "LoRa Gateway project"
SECTION = "libs/network"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=a2bdef95625509f821ba00460e3ae0eb"

SRC_URI = "https://github.com/Lora-net/lora_gateway/archive/v${PV}.tar.gz"

SRC_URI[md5sum] = "5d07f8471e1a67920787e3879afe0cb6"
SRC_URI[sha256sum] = "1a0447d5e8183d08e6dce5f739f6872b9c57824b98f4078830d5ee21b15782c1"

S = "${WORKDIR}/lora_gateway-${PV}"

CFLAGS_append = "-I ${S}/libloragw/inc -I ${S}/libloragw -I ${S}/util_pkt_logger/inc "

do_install() {
 bbplain "--------    Lora Gateway Install -----------------"
 install -d ${D}${bindir}
 install -d ${D}${docdir}
 install -d ${D}${libdir}/libloragw/inc
 install -d ${D}${includedir}/libloragw
 
 install -D -m 0644 ${B}/libloragw/inc/* ${D}${includedir}/libloragw
 
 install -D -m 0644 ${B}/libloragw/inc/* ${D}${libdir}/libloragw/inc
 install -D -m 0644 ${B}/libloragw/libloragw.a ${D}${libdir}/libloragw/libloragw.a
 install -D -m 0644 ${S}/libloragw/library.cfg ${D}${libdir}/libloragw/library.cfg
 
 install ${B}/libloragw/test_* ${D}${bindir}
 install ${B}/util_*/util_* ${D}${bindir}
 install ${S}/*.sh ${D}${bindir}
 
 install -D -m 0644 ${S}/readme.md ${D}${docdir}/libloragw/changelog.md
 install -D -m 0644 ${S}/libloragw/readme.md ${D}${docdir}/libloragw/README.md
 install -D -m 0644 ${S}/util_lbt_test/readme.md ${D}${docdir}/libloragw/util_lbt_test.md
 install -D -m 0644 ${S}/util_pkt_logger/readme.md ${D}${docdir}/libloragw/util_pkt_logger.md
 install -D -m 0644 ${S}/util_spectral_scan/readme.md ${D}${docdir}/libloragw/util_spectral_scan.md
 install -D -m 0644 ${S}/util_spi_stress/readme.md ${D}${docdir}/libloragw/util_spi_stress.md
 install -D -m 0644 ${S}/util_tx_continuous/readme.md ${D}${docdir}/libloragw/util_tx_continuous.md
 install -D -m 0644 ${S}/util_tx_test/readme.md ${D}${docdir}/libloragw/util_tx_test.md
 
 install -D -m 0644 ${S}/util_pkt_logger/global_conf.json ${D}${docdir}/libloragw/global_conf.json
 install -D -m 0644 ${S}/util_pkt_logger/local_conf.json ${D}${docdir}/libloragw/local_conf.json
}

PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"

PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev"

# Avoid QA Issue: No GNU_HASH in the elf binary
INSANE_SKIP_${PN} = "ldflags"

FILES_${PN}-dbg = " \
 ${bindir}/.debug \
 ${libdir}/libloragw/.debug \
"
FILES_${PN} = " \
 ${bindir}/* \
 ${docdir}/* \
"
FILES_${PN}-dev = " \
 ${includedir}/libloragw/* \
"
FILES_${PN}-staticdev = " \
 ${libdir}/libloragw/inc/*.h \
 ${libdir}/libloragw/*.a \
 ${libdir}/libloragw/*.cfg \
"
FILES_${PN}-doc = " \
 ${docdir} \
"




$ packet.bb
SUMMARY = "LoRa network packet forwarder project"
SECTION = "libs/network"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=22af7693d7b76ef0fc76161c4be76c45"

SRC_URI = "https://github.com/Lora-net/packet_forwarder/archive/v${PV}.tar.gz"

SRC_URI[md5sum] = "a1f942e0cc7b02d604b11c8cb5f2a029"
SRC_URI[sha256sum] = "e68fadf6f1d2e5e7b601e504d5efb48b0a8f374c2c29c0476ab2fe9db68d33ae"

DEPENDS += "lora-gateway" 

S = "${WORKDIR}/packet_forwarder-${PV}"

CFLAGS_append = "-I ${includedir}/libloragw -I ${S}/lora_pkt_fwd/inc -I ${S}/util_tx_test/inc "

do_configure_prepend() {
 export LGW_PATH="${STAGING_LIBDIR}/libloragw"
}

do_compile_prepend() {
 export LGW_PATH="${STAGING_LIBDIR}/libloragw"
}

do_install() {
        bbplain "--------    Lora Packet Forward Install -----------------"
 install -d ${D}${bindir}
 install -d ${D}${docdir}/lora-pkt-fwd/conf
 
 install ${B}/lora_pkt_fwd/lora_pkt_fwd ${D}${bindir}
 install ${B}/util_*/util_* ${D}${bindir}
 
 install -D -m 0644 ${S}/PROTOCOL.TXT ${D}${docdir}/lora-pkt-fwd/PROTOCOL.TXT
 install -D -m 0644 ${S}/lora_pkt_fwd/readme.md ${D}${docdir}/lora-pkt-fwd/readme.md
 install -D -m 0644 ${S}/lora_pkt_fwd/global_conf.json ${D}${docdir}/lora-pkt-fwd/global_conf.json
 install -D -m 0644 ${S}/lora_pkt_fwd/local_conf.json ${D}${docdir}/lora-pkt-fwd/local_conf.json
 install -D -m 0755 ${S}/lora_pkt_fwd/update_gwid.sh ${D}${docdir}/lora-pkt-fwd
 install -D -m 0644 ${S}/lora_pkt_fwd/cfg/*.json.* ${D}${docdir}/lora-pkt-fwd/conf
 
 rm -f ${D}${bindir}/util_tx_test
 rm -f ${D}${bindir}/.debug/util_tx_test
}

PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"

PACKAGES = "${PN}-dbg ${PN} ${PN}-doc"

# 상위에서 설명한 QA관련에러 
# Avoid QA Issue: No GNU_HASH in the elf binary
INSANE_SKIP_${PN} = "ldflags"

FILES_${PN}-dbg = " \
 ${bindir}/.debug \
"
FILES_${PN} = " \
 ${bindir}/* \
 ${docdir}/* \
"
FILES_${PN}-doc = " \
 ${docdir} \
"

$ packet.bbappend

## files로 만들경우, 기본 FILEPATH에 포함이 되어있으므로, 간단히 관리되며, Package 와 Version 별로 관리시 다음과 같이 관리  
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
SRC_URI += "file://001_packet_forwarder_lora_pkt_fwd.c.patch"
SRC_URI += "file://002_packet_forwarder_global_conf.json.patch"

ROOTFS_PREPROCESS_COMMAND
ROOTFS_POSTPROCESS_COMMAND
SDK_POSTPROCESS_COMMAND
POPULATE_SDK_POST_TARGET_COMMAND
POPULATE_SDK_POST_HOST_COMMAND
IMAGE_POSTPROCESS_COMMAND
IMAGE_PREPROCESS_COMMAND

ROOTFS_POSTINSTALL_COMMAND
           
  https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-1.6-variable-changes-variable-entry-behavior

Yocto PTEST
  https://wiki.yoctoproject.org/wiki/Ptest
  https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#testing-packages-with-ptest


Image BB File 예제
  https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/images/build-appliance-image_15.0.0.bb

Image BB File 예제와 PATCH
  https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips

MD5 Checksum
  https://docs.windriver.com/bundle/Wind_River_Linux_Toolchain_and_Build_System_Users_Guide_8.0_1/page/tan1478821620236.html

  http://variwiki.com/index.php?title=Yocto_Build_Release

  https://stackoverflow.com/questions/50906048/bitbake-recipes-simple-file-copy
  https://community.nxp.com/thread/472820
  https://stackoverflow.com/questions/45614578/enable-systemd-services-using-yocto
  https://linux.systemv.pe.kr/centos-7-systemd-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/
  https://chhanz.github.io/linux/2019/01/18/linux-how-to-create-custom-systemd-service/
  https://www.freedesktop.org/software/systemd/man/systemd.network.html

  https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-INSANE_SKIP

Raspberry-Pi3 와 Linux Yocto 기본구성 과 이해

1. Yocto 구성설명 

Yocto의 Quick Build 방법과 기존에 존재하는 Layer를 쉽게 추가하는 방법을 아래의 링크에서 쉽게 설명을 해주고 있으므로, 반드시 알아두자

• Yocto의 사용법 (Cookbook)

Yocto에 대한 현재 Quick Guide / Reference Manul 와 Cookbook Topics 에서 쉽게확인
  https://wiki.yoctoproject.org/wiki/Cookbook

• OS Image에 추가하는 방법 (Cookbook Topics)

아래의 구성할 문서의 순서랑 거의 동일하며 Layer 추가하는 방법 및 수정방법이 괜찮다
  https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image

• Application 개발관련내용(Cookbook Topics) 

기존의 bitbake-layers 와 다르게 devtool 을 이용한 recipe 추가방법이 새로움
  https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK

• Yocto 기본사용법확인

이전에 Yocto Reference Manual 기반으로 필요한 환경변수 및 구조설명
  https://ahyuo79.blogspot.com/2015/10/yocto.html

https://yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#what-is-the-yocto-project

• Layer 의 우선순위 (Layer Priority)

이전에 $ bitbake-layers show-layers 명령으로 우선순위를 보기는 했지만 우선순위 동작원리를 미쳐 파악을 못했다.

$ bitbake-layers show-layers  // Layer Priority 확인 및 구성확인 

$ bitbake-layers layerindex-show-depends meta-raspberrypi    // meta-raspberrypi의 의존성 확인, Layer를 추가할 때 의존성을 확인필요 

$ bitbake-layers -h 
usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h]  ...

BitBake layers utility

optional arguments:
  -d, --debug           Enable debug output
  -q, --quiet           Print only errors
  -F, --force           Force add without recipe parse verification
  --color COLOR         Colorize output (where COLOR is auto, always, never)
  -h, --help            show this help message and exit

subcommands:
  
    add-layer           Add one or more layers to bblayers.conf.
    remove-layer        Remove one or more layers from bblayers.conf.
    flatten             flatten layer configuration into a separate output
                        directory.
    show-layers         show current configured layers.
    show-overlayed      list overlayed recipes (where the same recipe exists
                        in another layer)
    show-recipes        list available recipes, showing the layer they are
                        provided by
    show-appends        list bbappend files and recipe files they apply to
    show-cross-depends  Show dependencies between recipes that cross layer
                        boundaries.
    layerindex-fetch    Fetches a layer from a layer index along with its
                        dependent layers, and adds them to conf/bblayers.conf.
    layerindex-show-depends
                        Find layer dependencies from layer index.
    create-layer        Create a basic layer

Use bitbake-layers  --help to get help on a specific command

https://dornerworks.com/blog/building-linux-with-yocto

상위 사이트에서 Layer의 우선순위에 대해서 너무 쉽게 그림으로 설명을 해주었지만,궁금한 사항이 두 가지가 더 생겼다.

• 궁금사항 

1. Layer의 우선순위는 어떻게 정해지는 것인가? 
2. Recipe의 우선순위는 어떻게 정해지는가? 

1번째의 질문의 답은 처음 conf/bblayers.conf에서 정해지는 것으로 착각했으나,  각 개별 Layer의 conf에  BBFILE_PRIORITY_xxx , suffix는 layer 이름에 의해 정해진다.

• meta-oe Layer 의 예제 (oe는 open embedded 약어)

$ vi meta-openembedded/meta-oe/conf/layer.conf    // 각 Layer의 conf에 의해 정의됨

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_PRIORITY_openembedded-layer = "6"        // openembedded layer 우선순위 

LAYERDEPENDS_openembedded-layer = "core"        //의존성 

LAYERSERIES_COMPAT_openembedded-layer = "thud warrior zeus"  // Yocto version 호환성 

• meta-networking Layer 예제

$ vi meta-openembedded/meta-networking/conf/layer.conf 

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \              // 등록되는 순서에 의해 동작될것이라고 생각 
            ${LAYERDIR}/recipes-*/*/*.bbappend"


BBFILE_PRIORITY_networking-layer = "5"     //networking layer의 우선순위 (같은 meta-openembdedded에 속해있지만 다름)

LAYERDEPENDS_networking-layer = "core"                // 의존성이 상당함 
LAYERDEPENDS_networking-layer += "openembedded-layer"
LAYERDEPENDS_networking-layer += "meta-python"

LAYERSERIES_COMPAT_networking-layer = "thud warrior zeus"

2번째의 질문의 답은 처음 Layer의 conf에서 BBFILES의 등록되는 순서가 아닐까 역시 잠시 착각 했는데, BBFILES은 등록만 할뿐 모든 Recipe는 사용하지 않는다는 사실을 깜빡했다.
잘 생각을 해보면, 최종 target image.bb파일이 존재하여, IMAGE_INSTALL에 들어간 Package들만을 설치진행한다.
기본으로 설치되는 부분은 class라는 공유개념이 존재하며,모든 recipe들은 사용하지 않는다.
즉  image -> core-image ->  include ***.bb 확장되어가는 구조


2. Raspberry Pi  개발환경 구성

1. OS: Ubuntu 16.04_LTS 64bit 
2. Window 기반의 Virtual Box 사용 

• 기본설치 

$ sudo apt install chrpath  diffstat gawk libncurses5-dev texinfo  

makeinfo -> texinfo 변경


2.1 Raspberry PI 관련사항 

• Raspberry PI 설정 및 전체문서   

  https://wikidocs.net/book/483

• Raspberry PI Kernel 

  https://wikidocs.net/3243
  https://wikidocs.net/3244

• Raspberry Android Build 

  http://airpage.org/xe/project_data/25990


2.2  Raspberry Pi Yocto 전체구성 


상위 Raspberry PI Yocto 구성 를 보면  사용할 GIT는 아래와 같이 세개로 구성이 된다.

• 기본 Yocto 시스템  및 추가 metalayer들 

1. git://git.yoctoproject.org/poky       // 기본 Yocto System 인 Poky
2. git://git.openembedded.org/meta-openembedded  // Yocto의 meta-layer (meta-oe) 추가 
3. https://github.com/agherzan/meta-raspberrypi  // Yocto의 meta-layer (meta-raspberrypi) 추가 

• Raspberry Pi Yocto 기본사용법 참고 사이트 

  http://www.jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html
  http://www.yocto.co.kr/2016/01/yocto-project-2.html
  http://kernelhacks.com/raspberry-pi-3-with-yocto/


2.3 Yocto 구성 및 meta layer 추가 

Yocto의 Reference Manual에 Reference Distribution Layer인 Poky를 구성한 후 각 필요한 meta layer들을 각각 추가하여 구성한다.

1. 필요한 Raspberry Pi를 위한 BSP Layer 추가 
2. Emdedded 관련된 기본인 Base Layer 추가

• Yocto의 기본인 Poky (Reference Distribution Layer) 구성 

Yocto의 기본시스템이 Pocky를 git로 download하여 아래와 같이 구성을 확인하자

$ mkdir raspberrypi
$ cd raspberrypi
$ git clone -b master  git://git.yoctoproject.org/poky

$ tree poky -L 1
poky
├── bitbake   // bin에 bitbake , bitbake-layers 가 존재하므로 중요   
├── contrib
├── documentation
├── LICENSE
├── LICENSE.GPL-2.0-only
├── LICENSE.MIT
├── meta
├── meta-poky
├── meta-selftest
├── meta-skeleton
├── meta-yocto-bsp
├── oe-init-build-env
├── README.hardware -> meta-yocto-bsp/README.hardware
├── README.OE-Core
├── README.poky -> meta-poky/README.poky
├── README.qemu
└── scripts  // devtool늘 비롯하여 각종 oe-xxxxx tools 제공 

$ cd poky
$ ls
LICENSE     README.hardware  README.qemu  documentation  meta-poky      meta-skeleton   oe-init-build-env
README.LSB  README.poky      bitbake      meta           meta-selftest  meta-yocto-bsp  scripts

  http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/

• poky 에 meta-raspberrypi (BSP Layer) 추가 

$ pwd
/home/jhlee/raspberrypi/poky

$ git clone -b master https://github.com/agherzan/meta-raspberrypi

$ tree -L 1 meta-raspberrypi
meta-raspberrypi
├── classes
├── conf
├── COPYING.MIT
├── docs
├── dynamic-layers
├── files
├── README.md
├── recipes-bsp
├── recipes-connectivity
├── recipes-core
├── recipes-devtools
├── recipes-graphics
├── recipes-kernel
├── recipes-multimedia
└── wic


$ ls
LICENSE     README.hardware  README.qemu  documentation  meta-openembedded  meta-raspberrypi  meta-skeleton   oe-init-build-env
README.LSB  README.poky      bitbake      meta           meta-poky          meta-selftest     meta-yocto-bsp  scripts

  https://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/
  https://github.com/agherzan/meta-raspberrypi
  http://meta-raspberrypi.readthedocs.io/en/latest/readme.html
  http://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/

• poky 에 meta-oe (Base Layer) 추가 

$ pwd
/home/jhlee/raspberrypi/poky

$ git clone -b master git://git.openembedded.org/meta-openembedded 

$ tree -L 1 meta-openembedded/
meta-openembedded/
├── contrib
├── COPYING.MIT
├── meta-filesystems
├── meta-gnome
├── meta-initramfs
├── meta-multimedia  // 이 아래의 4개의 layer만  rpi-build/conf/bblayers.conf 에 추가 
├── meta-networking
├── meta-oe
├── meta-perl
├── meta-python
├── meta-webserver
├── meta-xfce
└── README

  https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
  http://cgit.openembedded.org/meta-openembedded/tree/

• Yocto poky 에서 구조확인가능 

  http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/


2.4 이외의 meta-layer 추가방법  

Cookbook을 보면 자세히 나오며 각각 Layer들을 추가하여 확장하기가 쉽다. 다만, Type은 반드시 확인을 해야한다.

• OpenEmbeded Layer Index 의 meta-oe Layer 검색

1. meta-oe (meta-openembedded)  Layer Type Base를 찾음 
2. meta-raspberrypi  검색 과 Layer Type BSP 확인 

Reference Manual에는 Layer Type은 3가지밖에 없지만, 이곳에는 다음과 같이 더 분류를 하고 의미가 조금 다른 것 같다.

• Layer Type 

1. Base: Emdedded에서 기본 Layer로 개발 Tools 및 Kernel 관련부부구성 
2. Machine (BSP) : 각 개별 Board에 맞게 BSP 가 구성되어있어 선택 
3. Distribution : Poky를 기반으로 확장된 배포판으로 구성되어짐
4. Miscellaneous :  개발환경 혹은 특정 ARCH에 의존적으로 구성이됨 
5. Software : 쉽게 추가가능한 Opensource (이 Layer를 추가)

Base는 현재 meta-oe 와 openembedded-core 두 종류로 제공하고 있지만, meta-oe만 주로 사용한다

1. meta-oe : Embedded에서 필요한 개발 Tool 및 Kernel
2. openembedded-core:  많은 부분이 poky와 중복되는 것 같음 

OpenEmbedded Layer Index
  https://layers.openembedded.org/layerindex/branch/master/layers/

Yocto Site
  http://git.yoctoproject.org/cgit.cgi/

3. Yocto의 설정확인 및 변경 

bitbake를 사용하기 위해서 아래와 같이 기본빌드환경을 설정해줘야 한다

pocky 안에 oe-init-build-env를 실행하면, bitbake 사용 및 rpi-build directory가 생성이 된다.
물론 그냥 poky안에서 oe-init-build는 상관은 없지만, 모든 빌드내용이 rpi-build에 저장되기때문에 이를 외부를 분리하는 것이다.

$ source poky/oe-init-build-env rpi-build

build directory(rpi-build) 의 이름을 변경을 해도 상관없음

• Raspberry PI  Yocto 전체구성

물론 rpi-build를 poky 안에도 생성이 가능하지만 이를 외부를 분리하여 Yocto와 Build 부분을 분리한다.

$ tree -d -L 2
├── poky
│   ├── bitbake
│   ├── documentation
│   ├── meta
│   ├── meta-openembedded  // 추가될 layers로 하위 디렉토리에 layer가 존재 
│   ├── meta-poky
│   ├── meta-raspberrypi  // 추가될 layer
│   ├── meta-selftest
│   ├── meta-skeleton
│   ├── meta-yocto-bsp
│   └── scripts
└── rpi-build   // 이곳에서 빌드를 진행하므로, 추후 제거 할때도 이부분만 제거 (2.1 이후 생성)
    ├── cache 
    ├── conf             // 빌드할 Layers 및 MACHINE  설정 
    ├── downloads        // GIT Download   
    ├── sstate-cache
    └── tmp              // tmp/deploy/image/machine/xxxxx  배포 

• rpi-build 의 user configuration 설정 

1. ./conf/bblayers.conf     // build할 Layer 추가 
2. ./conf/local.conf         // build될 machine 설정 

3.1 rpi-build/conf/bblayers.conf  

본인이 bitbake를 이용하여 빌드하고자하는 각 Layer들을 적용을 하자

• rpi-build/conf/bblayers.conf 에 Layer 추가  

meta-openembedded의 경우 다수의 meta-layer로 구성이 되어있으므로 아래와 같이 추가.

$ cd rpi-build 
$ vi ./conf/bblayers.conf
.......
BBLAYERS ?= " \
  /home/jhlee/raspberrypi/poky/meta \
  /home/jhlee/raspberrypi/poky/meta-poky \
  /home/jhlee/raspberrypi/poky/meta-yocto-bsp \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-oe \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-multimedia \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-networking \
  /home/jhlee/raspberrypi/poky/meta-openembedded/meta-python \
  /home/jhlee/raspberrypi/poky/meta-raspberrypi \
  "

3.2  rpi-build/conf/local.conf 

MACHINE의 설정 및 전체 변수관련부분 설정 MACHINE이 아니더라도 본인이 원하는 부분을 설정을 하면 전체 적용되므로 중요

• rpi-build/conf/local.conf 에 Machine 설정

이제 본인의 board machine을 찾았으니, 이를 적용하자 (상위 conf 제외한 이름)

$ cd rpi-build 
$ vi ./conf/local.conf 
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
MACHINE ?= "raspberrypi3-64"
# This sets the default machine to be qemux86 if no other machine is selected:
#MACHINE ??= "qemux86" 

3.3 MACHINE의 Config 확인 

conf/local.conf 에서 설정한 MACHINE 은 항상 동일한 이름으로 conf가 존재하며 이를 찾아 관련설정을  확실히 확인하자 

• MACHINE의 raspberrypi3-64.conf  확인 

$ cd pocky 
$ find . -name machine | xargs ls        // MACHINE의 이름을 모를 경우 모든 BSP Layer 검색 
./meta/conf/machine:
include         qemuarm.conf    qemuarm64.conf   qemumips.conf     qemumips64.conf  
qemuppc.conf    qemux86-64.conf qemux86.conf

./meta-raspberrypi/conf/machine:
include/                raspberrypi-cm3.conf    raspberrypi0-wifi.conf  raspberrypi2.conf       raspberrypi3.conf       
raspberrypi-cm.conf     raspberrypi.conf        raspberrypi0.conf       raspberrypi3-64.conf  

./meta-selftest/conf/machine:
qemux86copy.conf

./meta-yocto-bsp/conf/machine:
beaglebone-yocto.conf  edgerouter.conf  genericx86-64.conf  genericx86.conf  include  mpc8315e-rdb.conf

or 
$ find . -name raspberrypi3-64.conf  // MACHINE 이름을 정확히 아는 경우 

주로 확인해야 할 것이 UBOOT 설정 과 KERNEL 및 Device Tree 가 될 것 같다

• 지원 MACHINE 이름 

  https://layers.openembedded.org/layerindex/branch/master/machines/


4. Bitbake로 기본 빌드 

bitbake는 상위 pocky->bitbake안에 존재하므로 이것이 PATH에 적용이 되지 않을 경우는 아래와 같이 동작하지 않는다.
다시 설정하고 싶다면 2.를 다시 설정하면 되며, 상위 저장된 설정도 기억하고 있다.

• Bitbake로 빌드진행  

$ bitbake core-image-base 

빌드를 할 경우, 상당한 시간과 용량을 필요로 하며, 용량은 VDI의 경우 최소 50G로 잡자.
처음 30G (Ubuntu까지 설치된 상태)로 빌드를 진행을  했는데, 용량부족으로 실패했다.


4.1 core-image-minimal 와 core-image-base 차이 

yocto에서 image를 생성하기 위해서 상위 target 설정이외 sato or x11 등 다양하게 확장제공하고 있지만, 일단 2개의 정확한 차이를 알아두고 어떻게 확장하는지 알아보자.

• bitbake에서 image를 만들때 가장 많이 사용하는 Target or Recipe 

1. core-image-minimal: 기본으로 boot하고 기본동작되는 확인
2. core-image-base: core-image-minimal 에 MACHINE의 HW의 모든기능을 제공 및 테스트 가능 

• core-image-base 와 core-image-minimal 각 위치확인 

$ pwd
/home/jhlee/raspberrypi/poky

$ find . -name core-image-minimal*
./meta/recipes-core/images/core-image-minimal-mtdutils.bb
./meta/recipes-core/images/core-image-minimal-initramfs.bb
./meta/recipes-core/images/core-image-minimal.bb
./meta/recipes-core/images/core-image-minimal-dev.bb

$ find . -name core-image-base*
./meta/recipes-core/images/core-image-base.bb

• core-image-minimal 의 구성확인  

1. IMAGE_INSTALL : packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL} 직접정의 
2. inherit core-image : core-image*.bbclass를 사용 

$ cat ./meta/recipes-core/images/core-image-minimal.bb // 아래의 core-image.bbclass 부분과 비교 
SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit core-image

IMAGE_ROOTFS_SIZE ?= "8192"
IMAGE_ROOTFS_EXTRA_SPACE_append = "${@bb.utils.contains("DISTRO_FEATURES", "systemd", " + 4096", "" ,d)}" 

• core-image-base 의 구성  (core-image.bbclass의 IMAGE_INSTALL 사용)

1. IMAGE_INSTALL:  설정정의가 없으므로, core-image*.bbclass에 정의된 것으로 동작 
2. inherit core-image : core-image*.bbclass를 사용 

$ cat ./meta/recipes-core/images/core-image-base.bb
SUMMARY = "A console-only image that fully supports the target device \
hardware."

IMAGE_FEATURES += "splash"

LICENSE = "MIT"

inherit core-image 

• core-image.bbclass  ( inherit core-image 검색)

core-image-minimal 과 core-image-base 의 차이는 IMAGE_INSTALL 차이 
core-image-base의 경우 packagegroup-base-extended 부분이 추가됨

$ find . -name core-image*bb* 
..
./meta/classes/core-image.bbclass
..
$ cat ./meta/classes/core-image.bbclass //  inherit core-image 관련부분 확인 

CORE_IMAGE_BASE_INSTALL = '\
    packagegroup-core-boot \
    packagegroup-base-extended \
    \
    ${CORE_IMAGE_EXTRA_INSTALL} \
    '

IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"  

inherit image 

• image.bbclass (inherit image)

image를 만드는 시작점인 것 같으며, 소스를 보면 전체 동작방식을 대충 이해가 가며 python으로도 구성이되어 소스내용이 길다.

$ find . -name image*bb*  // inherit image 관련부분 검색  
..
./meta/classes/image.bbclass

$ cat ./meta/classes/image.bbclass  
IMAGE_CLASSES ??= ""

# rootfs bootstrap install
# warning -  image-container resets this
ROOTFS_BOOTSTRAP_INSTALL = "run-postinsts"

# Handle inherits of any of the image classes we need
IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
# Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base
# in the non-Linux SDK_OS case, such as mingw32
IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
IMGCLASSES += "image_types_wic"
IMGCLASSES += "rootfs-postcommands"
IMGCLASSES += "image-postinst-intercepts"
inherit ${IMGCLASSES}
..... 너무길어 중략 (do_rootfs 비롯하여 다른 중요부분도 한번봐야함)

공통적으로 inherit core-image로 공유해서 사용되어지고 있으며, 이 부분은 bbclass 로 되어있고, 이 공유하며,
중요한 부분은 IMAGE_INSTALL 의 정의차이를 보면 될 것 같다.

아래링크참조
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-classes-core-image
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-classes-image
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html


4.2 core-image-xxx 확장 및 본인의 Image target 확장 

recipe 내에서 include recipe-core/images/core-image-base.bb 추가하여 확장하는 구조이다.

• raspberry pi target recipe 확장분석  

core-image-minimal 기반으로 본인이 필요한 Package들을 IMAGE_INSTALL 추가하는 방식
rpi-basic-image는 앞으로 안 사용되어질 거라고 하는데, core-image-base 로 하면 될 것 같다.

$ vi meta-raspberrypi/recipes-core/images/rpi-basic-image.bb  
# Base this image on core-image-minimal
include recipes-core/images/core-image-minimal.bb

# Include modules in rootfs
IMAGE_INSTALL += " \
        kernel-modules \
        "

SPLASH = "psplash-raspberrypi"

IMAGE_FEATURES += "ssh-server-dropbear splash"

do_image_prepend() {
    bb.warn("The image 'rpi-basic-image' is deprecated, please use 'core-image-base' instead")
}

• 나만의 target image recipe 로 확장 

IMAGE_INSTALL에 본인이 필요한 Package들을 정의하여 넣고, 새로운 Target Image recipe로 정의

$ vi meta-raspberrypi/recipes-core/images/core-image-jhlee.bb  
SUMMARY = "JHLee Sample Test Image"

# Base this image on core-image-minimal
include recipes-core/images/core-image-base.bb

# ssh server and systemd and tcpdump
IMAGE_INSTALL += "openssh systemd-analyze tcpdump"
        
export IMAGE_BASENAME = "core-image-jhlee"

recipe 검색
  https://layers.openembedded.org/layerindex/branch/master/recipes/


4.3 SD Image 확인 및 Writing Image

• How to find SD image

bitbake로 core-image-base 빌드 한 후 deploy에서 확인 (SD Image)

$ cd rpi-build/tmp/deploy/images/raspberrypi3-64
$ ls *.rpi*
core-image-base-raspberrypi3-64-20180526144104.rootfs.rpi-sdimg  core-image-base-raspberrypi3-64.rpi-sdimg 

• How To write SD Image 

Linux에서 SD Disk를 접근가능하다면 Image Writing을 할수 있다. ( Virtual Box도 연결해서 하면되지만 절차가 복잡)

$ sudo dd if=core-image-base-raspberrypi3-64.rpi-sdimg of=/dev/sde bs=1M   // 이부분 SD Disk와 연결되었을 경우

상위명령어 대신 이 Image 파일을 Window로 가져와서 Win32DiskImager를 이용하자

• Win32DiskImager

  https://ahyuo79.blogspot.com/2016/05/sd-card-writer-window.html


4.4 Bitbake Build 분석 및 에러사항

• Bitbake 빌드 분석 

WARNING: Host distribution "ubuntu-14.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Build Configuration:
BB_VERSION           = "1.37.0"
BUILD_SYS            = "x86_64-linux"        // HOST의 Build System 
NATIVELSBSTRING      = "universal-4.8"       // Ubuntu 일 경우 ubuntu로 표시  
TARGET_SYS           = "aarch64-poky-linux"  // Target system 이름 ARM을 사용할 경우 ARM이 표시됨 
MACHINE              = "raspberrypi3-64"     // Board의 Machine 이름   
DISTRO               = "poky"
DISTRO_VERSION       = "2.5"
TUNE_FEATURES        = "aarch64"              // Compiler 관련 설정  
TARGET_FPU           = ""                     // Hardware FPU 설정 
meta                 
meta-poky            
meta-yocto-bsp       = "master:13cc30cd7de4841990b600e83e1249c81a5171dd"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "master:d59b9806f743cea0168cddf942a31dcf446839e6"
meta-raspberrypi     = "master:7f7bc9e778b6def018c451ecb23f5169cd18f5ed"

• 문제사항 1

  https://github.com/WebPlatformForEmbedded/meta-wpe/issues/151

$ bitbake core-image-base 
ERROR: Unable to start bitbake server
ERROR: Last 10 lines of server log for this session (/home/jhlee/raspberrypi/rpi-build/bitbake-cookerdaemon.log):
    self.cooker = bb.cooker.BBCooker(self.configuration, self.featureset)
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cooker.py", line 197, in __init__
    self.initConfigurationData()
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cooker.py", line 356, in initConfigurationData
    self.databuilder.parseBaseConfiguration()
  File "/home/jhlee/raspberrypi/poky/bitbake/lib/bb/cookerdata.py", line 317, in parseBaseConfiguration
    raise bb.BBHandledException
bb.BBHandledException
ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH, please install them in order to proceed:
  chrpath gawk makeinfo

아래 Package 설치 후 문제해결 (상위에 모두 표시)

$ sudo apt install gawk
$ sudo apt-get install chrpath
$ sudo apt-get install texinfo

• 문제사항 2

WARNING: Host distribution "ubuntu-14.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
.......
ERROR: mpfr-native-3.1.5-r0 do_compile: oe_runmake failed
ERROR: mpfr-native-3.1.5-r0 do_compile: Function failed: do_compile (log file is located at /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203)
ERROR: Logfile of failure stored in: /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203
....
| x86_64-linux-libtool:   error: 'set_si_2exp.lo' is not a valid libtool object
| make[2]: *** [libmpfr.la] Error 1
| make[2]: Leaving directory `/home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/build/src'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/build/src'
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/jhlee/raspberrypi/rpi-build/tmp/work/x86_64-linux/mpfr-native/3.1.5-r0/temp/log.do_compile.13203)
ERROR: Task (virtual:native:/home/jhlee/raspberrypi/poky/meta/recipes-support/mpfr/mpfr_3.1.5.bb:do_compile) failed with exit code '1'

Ubuntu 16으로 변경 후 문제 해결 (처음 Ubuntu 14.04로 진행함)
  https://stackoverflow.com/questions/36226828/yocto-bitbake-script-not-displaying-echo-statement