20160712_jeffrey - silenceuncrio/diary GitHub Wiki
-
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 - 沒有 buildubifs
格式 rootfs -
1950 -
<BUILD_DIR>/conf/local.conf
-MACHINE ??= 'imx6ul14x14ddr3arm2'
-bitbake core-image-minimal
早上十點 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)
M300 meeting
目前 schedule 順延到十月底
morris 分享一個聲音偵測器 SoC
- BelaSigna R281是“一直听”的,将检测经用户培训后的单个触发短语。当检测到触发短语时发出唤醒信号。在本视频中,我们将为您展示
- BelaSigna® R281 : 一直听的语音触发方案
- BELASIGNA R281: Always-Listening, Voice Trigger Audio DSP System
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.
繼續 review 昨天的足跡
整理一下讓自己比較方便說故事
先將比較常用的目錄名稱做個簡稱
-
<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.inc
的do_compile()
終點的 do_compile()
正呼應了 起點的 -c compile
<YOCTO_DIR>/poky/meta/recipes-bsp/u-boot/u-boot.inc
的 do_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.inc
的 do_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
新增 <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"
關於什麼是 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
繼續做實驗
- 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"
}
作實驗前先看看有沒有能幫助實驗更順利的情報
情報 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
可以做實驗了
先做 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 了
整理一下 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
剛剛和 morris 去隔壁庫房試一下 alarm sensor
效果還不錯
目前可以拿一般手機用的充電器提供 5V 的電壓同時驅動 ESP8266 與 MIC
當偵測到警報便會亮起紅燈
目前這個簡單的樣品已經足夠業務去 demo 了
保持 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
目前的 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"