20160712_jeffrey - silenceuncrio/diary GitHub Wiki

Index

  • 0915 - alarm sensor - print("Alarm Detect!") - 順便點燈
  • 1130 - M300 meeting - schedule 順延 十月底
  • 1135 - 聲音偵測 SoC - BelaSigna R281
  • 1145 - review 昨天 實驗 過程 加強 YOCTO 認識
  • 1305 - review 昨天 足跡
  • 1310 - 整理 方便 說故事 - <YOCTO_DIR> <BUILD_DIR> <UBOOT_DIR>
  • 1410 - <UBOOT_DIR>/configs/mx6ul_14x14_evk_nand_config - 新增
  • 1425 - CONFIG_SYS_EXTRA_OPTIONS="...,SYS_BOOT_NAND" - compile-time - CONFIG_SYS_BOOT_NAND flag
  • 1520 - 實驗 - UBOOT_CONFIG = "sd" - UBOOT_CONFIG = "nand"
  • 1610 - 幫助 實驗 順利 情報
  • 1630 - 實驗 - UBOOT_CONFIG = "sd" - UBOOT_CONFIG = "nand"
  • 1710 - 整理 alarm sensor code - 可能 config
  • 1750 - 隔壁庫房 試 alarm sensor
  • 1915 - UBOOT_CONFIG = "nand" - log - 沒有 build ubifs 格式 rootfs
  • 1950 - <BUILD_DIR>/conf/local.conf - MACHINE ??= 'imx6ul14x14ddr3arm2' - bitbake core-image-minimal

0915

早上十點 M300 開會前先作一些 alarm sensor

根據上禮拜四在隔壁庫房實際使用警報器做的測試後調整的 code 如下

info_cnt = 0
INFO_MAX = 4000

adc_val = 0


ADC_TRIGGER_LEVEL_HIGH = 750
ADC_TRIGGER_LEVEL_MEDIUM = 500
ADC_TRIGGER_LEVEL_LOW = 400

adc_trigger_level = ADC_TRIGGER_LEVEL_HIGH

adc_triggered_cnt = 0

ADC_TRIGGERED_MAX = 500

tmr.alarm(1, 1, tmr.ALARM_AUTO, function()
  if info_cnt < INFO_MAX then
    adc_val = adc.read(0)
    if adc_val > ADC_TRIGGER_LEVEL_LOW then
      adc_triggered_cnt = adc_triggered_cnt + 1
    end
    info_cnt = info_cnt + 1
  else
    print("adc_triggered_cnt: "..adc_triggered_cnt)
    if adc_triggered_cnt > ADC_TRIGGERED_MAX then
      print("Alarm Detect!")
    end
    info_cnt = 0
    adc_triggered_cnt = 0
  end  
end)

目前需要讓 print("Alarm Detect!") 時再順便點個燈

ADC_TRIGGER_LEVEL_HIGH = 500
ADC_TRIGGER_LEVEL_MEDIUM = 400
ADC_TRIGGER_LEVEL_LOW = 300
ADC_TRIGGERED_MAX = 500
INFO_MAX = 4000
LED_PIN = 0

info_cnt = 0
adc_val = 0
adc_trigger_level = ADC_TRIGGER_LEVEL_HIGH
adc_triggered_cnt = 0

gpio.mode(LED_PIN, gpio.OUTPUT)
gpio.write(LED_PIN, gpio.LOW)

tmr.alarm(1, 1, tmr.ALARM_AUTO, function()
  if info_cnt < INFO_MAX then
    adc_val = adc.read(0)
    if adc_val > ADC_TRIGGER_LEVEL_MEDIUM then
      adc_triggered_cnt = adc_triggered_cnt + 1
    end
    info_cnt = info_cnt + 1
  else
    print("adc_triggered_cnt: "..adc_triggered_cnt)
    if adc_triggered_cnt > ADC_TRIGGERED_MAX then
      print("Alarm Detect!")
      gpio.write(LED_PIN, gpio.HIGH)
    else
      gpio.write(LED_PIN, gpio.LOW)
    end
    info_cnt = 0
    adc_triggered_cnt = 0
  end  
end)

1130

M300 meeting

目前 schedule 順延到十月底

1135

morris 分享一個聲音偵測器 SoC

1145

review 昨天的實驗過程順便再加強對 YOCTO 的認識

BitBake supports these types of functions:

  • Shell Functions
    Functions written in shell script and executed either directly as functions, tasks, or both.
    They can also be called by other shell functions.
  • BitBake Style Python Functions
    Functions written in Python and executed by BitBake or other Python functions using bb.build.exec_func().
  • Python Functions
    Functions written in Python and executed by Python.
  • Anonymous Python Functions
    Python functions executed automatically during parsing.

Regardless of the type of function, you can only define them in class (.bbclass) and recipe (.bb or .inc) files.

Configures the UBOOT_MACHINE and can also define IMAGE_FSTYPES for individual cases.

Following is an example from the meta-fsl-arm layer.

    UBOOT_CONFIG ??= "sd"
    UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
    UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
    UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
    UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"

In this example, "sd" is selected as the configuration of the possible four for the UBOOT_MACHINE.
The "sd" configuration defines "mx6qsabreauto_config" as the value for UBOOT_MACHINE, while the "sdcard" specifies the IMAGE_FSTYPES to use for the U-boot image.

For more information on how the UBOOT_CONFIG is handled, see the uboot-config class.

1305

繼續 review 昨天的足跡

1310

整理一下讓自己比較方便說故事

先將比較常用的目錄名稱做個簡稱

  • <YOCTO_DIR> - Yocto Project layers 所在的目錄
    • M300/fsl-release-bsp/sources/
  • <BUILD_DIR> - build image 時所在的目錄
    • M300/fsl-release-bsp/build_small/
  • <UBOOT_DIR> - U-Boot source code 所在目錄
    • M300/fsl-release-bsp/build_small/tmp/work/imx6ulevk-poky-linux-gnueabi/u-boot-imx/2015.04-r0/git/

所以下面這些 file path

  • M300/fsl-release-bsp/sources/meta-fsl-arm/conf/machine/imx6ulevk.conf
  • M300/fsl-release-bsp/sources/poky/meta/recipes-bsp/u-boot/u-boot.inc
  • M300/fsl-release-bsp/build_small/conf/local.conf
  • M300/fsl-release-bsp/build_small/tmp/work/imx6ulevk-poky-linux-gnueabi/u-boot-imx/2015.04-r0/git/configs/mx6ul_14x14_evk_defconfig

可以變成

  • <YOCTO_DIR>/meta-fsl-arm/conf/machine/imx6ulevk.conf
  • <YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.inc
  • <BUILD_DIR>/conf/local.conf
  • <UBOOT_DIR>/configs/mx6ul_14x14_evk_defconfig

昨天追蹤的足跡的 起點 和 終點 分別是

  • 起點 - 在 <BUILD_DIR> 執行 bitbake u-boot-imx -c compile -vf
    • 編譯 U-Boot
  • 終點 - <YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.incdo_compile()

終點的 do_compile() 正呼應了 起點的 -c compile

<YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.incdo_compile() 的行為會被 <BUILD_DIR>/conf/local.conf 裡的 UBOOT_CONFIG 定義所影響

UBOOT_CONFIG 的定義要綜合下面兩個 file 來看

  • <YOCTO_DIR>/meta-fsl-arm/conf/machine/imx6ulevk.conf
  • <BUILD_DIR>/conf/local.conf

我們要關注的是 <YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.incdo_compile() 執行時的 UBOOT_CONFIG 定義

假設 <YOCTO_DIR>/meta-fsl-arm/conf/machine/imx6ulevk.conf 具有下面的內容

...
UBOOT_CONFIG     ??= "sd"
UBOOT_CONFIG[sd]   = "mx6ul_14x14_evk_config,sdcard"
UBOOT_CONFIG[nand] = "mx6ul_14x14_evk_nand_config,ubifs"
...

這就表示當

  • UBOOT_CONFIG = "sd"
    • UBOOT_MACHINE = "mx6ul_14x14_evk_config"
    • IMAGE_FSTYPES = "sdcard"
  • UBOOT_CONFIG = "nand"
    • UBOOT_MACHINE = "mx6ul_14x14_evk_nand_config"
    • IMAGE_FSTYPES = "ubifs"

由昨天的追蹤可知不同的 UBOOT_CONFIG 需要 <UBOOT_DIR>/configs/ 目錄下不同的 file

  • UBOOT_CONFIG = "sd"
    • <UBOOT_DIR>/configs/mx6ul_14x14_evk_defconfig
  • UBOOT_CONFIG = "nand"
    • <UBOOT_DIR>/configs/mx6ul_14x14_evk_nand_config

昨天當 UBOOT_CONFIG = "nand" 時發生的問題便是 <UBOOT_DIR>/configs/ 目錄下並不存在有 mx6ul_14x14_evk_nand_config

1410

新增 <UBOOT_DIR>/configs/mx6ul_14x14_evk_nand_config 不是難事

難的是該具有怎麼樣的內容

幸運的是 How-To use NAND boot on i.MX6UL EVK board 已經提供了現成的 mx6ul_14x14_evk_nand_config

內容為

CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL,SYS_BOOT_NAND"
CONFIG_ARM=y
CONFIG_TARGET_MX6UL_14X14_EVK=y
CONFIG_DM=y
CONFIG_DM_THERMAL=y

<UBOOT_DIR>/configs/mx6ul_14x14_evk_defconfig 的內容為

CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL"
CONFIG_ARM=y
CONFIG_TARGET_MX6UL_14X14_EVK=y
CONFIG_DM=y
CONFIG_DM_THERMAL=y

兩個檔案的內容差別只在於

  • UBOOT_CONFIG = "sd"
    • CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL"
  • UBOOT_CONFIG = "nand"
    • CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL,SYS_BOOT_NAND"

1425

關於什麼是 CONFIG_SYS_EXTRA_OPTIONS

google 到的都不是很直接的解釋

例如 [3/4] vexpress64: get rid of CONFIG_SYS_EXTRA_OPTIONS

The Versatile Express ARMv8 semihosted FVP platform is still using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure some compile-time flags.

不過合理的推測

當 UBOOT_CONFIG = "nand" 的時候

CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL,SYS_BOOT_NAND" 這樣的敘述

會讓 compile-time 多了 CONFIG_SYS_BOOT_NAND 這個 flag

有了這個認知我們就能理解 <UBOOT_DIR>/include/configs/mx6ul_14x14_evk.h 的內容

#if defined(CONFIG_SYS_BOOT_NAND)
#define CONFIG_EXTRA_ENV_SETTINGS \
	CONFIG_MFG_ENV_SETTINGS \
	CONFIG_VIDEO_MODE \
	"fdt_addr=0x83000000\0" \
	"fdt_high=0xffffffff\0"	  \
	"console=ttymxc0\0" \
	"bootargs=console=ttymxc0,115200 ubi.mtd=3 "  \
		"root=ubi0:rootfs rootfstype=ubifs "		     \
		CONFIG_BOOTARGS_CMA_SIZE \
		"mtdparts=gpmi-nand:64m(boot),16m(kernel),16m(dtb),-(rootfs)\0"\
	"bootcmd=nand read ${loadaddr} 0x4000000 0x800000;"\
		"nand read ${fdt_addr} 0x5000000 0x100000;"\
		"bootz ${loadaddr} - ${fdt_addr}\0"

#else
    ...
#endif

假設有了 CONFIG_SYS_BOOT_NAND 這個 compile-time flag 的話

macro CONFIG_EXTRA_ENV_SETTINGS 的定義便擁有了我們需要的

"mtdparts=gpmi-nand:64m(boot),16m(kernel),16m(dtb),-(rootfs)"

不過這等板子來了就能更明確知道 mtdparts 的值所帶來的影響

現階段是讓整個 bitbake build image 能依據 UBOOT_CONFIG 來產生相對應的 image

1520

繼續做實驗

  • UBOOT_CONFIG = "sd"
  • UBOOT_CONFIG = "nand"

<YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.inc 的 do_compile () 作原本該做的事

do_compile () {
    echo "do_compile()"
    if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
        sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' config.mk
    fi

    unset LDFLAGS
    unset CFLAGS
    unset CPPFLAGS

    if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]
    then
        echo ${UBOOT_LOCALVERSION} > ${B}/.scmversion
        echo ${UBOOT_LOCALVERSION} > ${S}/.scmversion
    fi
    
    if [ "x${UBOOT_CONFIG}" != "x" ]
    then
        for config in ${UBOOT_MACHINE}; do
            i=`expr $i + 1`;
            for type  in ${UBOOT_CONFIG}; do
                j=`expr $j + 1`;
                if [ $j -eq $i ]
                then
                    oe_runmake O=${config} ${config}
                    oe_runmake O=${config} ${UBOOT_MAKE_TARGET}
                    cp  ${S}/${config}/${UBOOT_BINARY}  ${S}/${config}/u-boot-${type}.${UBOOT_SUFFIX}
                fi
            done
            unset  j
        done
        unset  i
    else
        oe_runmake ${UBOOT_MACHINE}
        oe_runmake ${UBOOT_MAKE_TARGET}
    fi
    echo "do_compile() return"
}

1610

作實驗前先看看有沒有能幫助實驗更順利的情報

情報 1

The most important directory is WORKDIR/temp/, which has log files for each task (log.do_.pid) and contains the scripts BitBake runs for each task (run.do_.pid).

這個情報表示

假設我在 <BUILD_DIR> 做了 bitbake u-boot-imx -c xxx -vf

那麼 <UBOOT_DIR>/../temp/log.do_xxx.pid 便是我的記錄檔了

情報 2

bitbake u-boot-imx -c clean 會清空 <UBOOT_DIR> 也會刪掉 <UBOOT_DIR>/../temp/

情報 3

bitbake u-boot-imx -c unpack 會在 <UBOOT_DIR> 下長出原始的 source code

<UBOOT_DIR>/../temp/ 下會有 log

  • log.do_fetch.pid
  • log.do_unpack.pid

1630

可以做實驗了

先做 UBOOT_CONFIG = "sd" 實驗

依序執行

  • bitbake u-boot-imx -c clean
  • bitbake u-boot-imx -c unpack
  • bitbake u-boot-imx -c compile

得到 log.do_compile.16562

再作 UBOOT_CONFIG = "nand" 實驗

  • bitbake u-boot-imx -c clean
  • bitbake u-boot-imx -c unpack
  • <BUILD_DIR>/conf/local.conf 定義 UBOOT_CONFIG = "nand"
  • 新增 <UBOOT_DIR>/configs/mx6ul_14x14_evk_nand_config
    • CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6ul_14x14_evk/imximage.cfg,MX6UL,SYS_BOOT_NAND"
  • bitbake u-boot-imx -c compile

得到 log.do_compile.19968

兩種都成功 build 出 image 了

1710

整理一下 alarm sensor 的 code

-- adc trigger condition

ADC_TRIGGER_LEVEL_HIGH = 500
ADC_TRIGGER_LEVEL_MEDIUM = 400
ADC_TRIGGER_LEVEL_LOW = 300

info_cnt = 0
info_max = 4000 -- config: duration concern

adc_val = 0
adc_trigger_level = ADC_TRIGGER_LEVEL_MEDIUM -- config: sensitivity
adc_triggered_cnt = 0

adc_triggered_threshold = 500 -- config: alarm sound wave density

-- LED

LED_PIN = 0

gpio.mode(LED_PIN, gpio.OUTPUT)
gpio.write(LED_PIN, gpio.LOW)

-- collect info per 1ms, i.e. 1000 info per second

tmr.alarm(1, 1, tmr.ALARM_AUTO, function()
  if info_cnt < info_max then
    adc_val = adc.read(0)
    if adc_val > adc_trigger_level then
      adc_triggered_cnt = adc_triggered_cnt + 1
    end
    info_cnt = info_cnt + 1
  else
    print("adc_triggered_cnt: "..adc_triggered_cnt)
    if adc_triggered_cnt > adc_triggered_threshold then
      print("Alarm Detect!")
      gpio.write(LED_PIN, gpio.HIGH)
    else
      gpio.write(LED_PIN, gpio.LOW)
    end
    info_cnt = 0
    adc_triggered_cnt = 0
  end  
end)

可能會被 config 的 候選 有

  • info_max - 多少筆資料結算一次
  • adc_trigger_level - 被觸發的靈敏度
  • adc_triggered_threshold - 聲波越密(越持續)就越容易累積觸發的 counter

1750

剛剛和 morris 去隔壁庫房試一下 alarm sensor

效果還不錯

目前可以拿一般手機用的充電器提供 5V 的電壓同時驅動 ESP8266 與 MIC

當偵測到警報便會亮起紅燈

目前這個簡單的樣品已經足夠業務去 demo 了

1915

保持 UBOOT_CONFIG = "nand" 的狀態下

試著使用 bitbake core-image-minimal 來產生 image

log 在 <BUILD_DIR>/tmp/work/imx6ulevk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.29010

...
NOTE: The image creation groups are: [['ext3', 'tar'], ['sdcard']]
...

根本就沒有幫我 build ubifs 格式的 rootfs

1950

目前的 MACHINE=imx6ulevk

之前有印象使用 MACHINE=imx6ul14x14ddr3arm2 配合 <BUILD_DIR>/conf/local.conf 定義 UBOOT_CONFIG = "nand" 可以 build image 出來

  • 保持 UBOOT_CONFIG = "nand"
  • /M300/fsl-release-bsp/ 目錄
    • 執行 MACHINE=imx6ul14x14ddr3arm2 source setup-environment build_small
  • bitbake u-boot-imx -c clean
  • bitbake core-image-minimal

發現 MACHINE 還是 imx6ulevk

直接改 <BUILD_DIR>/conf/local.conf - MACHINE ??= 'imx6ul14x14ddr3arm2'

再執行 bitbake core-image-minimal

jeffrey@jeffrey-VirtualBox:~/M300/fsl-release-bsp/build_small$ bitbake core-image-minimal
...
Build Configuration:
BB_VERSION        = "1.26.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "Ubuntu-15.10"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "imx6ul14x14ddr3arm2"
...

這一次就確定 MACHINE = "imx6ul14x14ddr3arm2"

⚠️ **GitHub.com Fallback** ⚠️