目次: ROCK64/ROCKPro64
完全に自分のためのメモですが、ROCK64とTinker Boardで使用しているU-Bootのdistro bootの設定ファイル(extlinux.conf)を貼っておきます。
オリジナルのファイルにlinux-nextの起動用設定(label kernel-nextの部分)を追加しました。
menu title select kernel
label kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524
kernel /boot/vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
devicetreedir /boot/dtbs/4.4.132-1075-rockchip-ayufan-ga83beded8524
append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
label kernel-next
kernel /boot/Image
initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
fdt /boot/rk3328-rock64.dtb
append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
label kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524-memtest
kernel /boot/vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
devicetreedir /boot/dtbs/4.4.132-1075-rockchip-ayufan-ga83beded8524
append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest
クロスコンパイル用マシンにて実行 $ cd linux-next $ scp arch/arm64/boot/Image arch/arm64/boot/dts/rockchip/rk3328-rock64.dtb 192.168.1.xxx:~/ ROCK64にて実行 $ sudo cp Image /boot/ ; sudo cp rk3328-rock64.dtb /boot/ ; sync ; sudo reboot
CPUがAArch64なので生成されるイメージファイルはImageです。デバイスツリーはrk3328-rock64.dtbです。ネットワーク経由でROCK64のユーザ(なんでもよいですが)のホームディレクトリにコピーし、ボード側で /bootにコピーして使っています。またinitrdはオリジナルのものを拝借しています。
1行目のmenu title select kernelが結構大事で、この行を書いておくとU-Bootがカーネルを起動する際に下記のような選択肢が表示されます。
Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 1433 bytes read in 28 ms (49.8 KiB/s) select kernel 1: kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524 2: kernel-next 3: kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524-memtest Enter choice:
この設定はとにかくボードからSDカードの抜き差しをやりたくない一心でできています。
普段はbootメニューで2番を選びlinux-nextカーネルを起動します。もし起動しないカーネルを書き込んでしまったり、ネットワークが死んでいるカーネルを書き込んでしまい、カーネルの更新ができなくなったときは、リブートし1番を選び元々書かれていたカーネルを起動して復旧させます。
何も選択せず放置すると1番が勝手に選ばれますので、おかしくなったら電源をON/OFFして放置すれば、必ずオリジナルのカーネルが起動します。ボードが少し遠くに置いてあって、AC電源ON/OFFからU-Bootの選択肢タイムアウトまでの間にキー入力ができないので、このような設定にしています……。
Tinker Boardの設定も同じ思想で作っています。
# cat /boot/extlinux/extlinux.conf
menu title select kernel
label kernel-4.4
kernel /zImage
fdt /rk3288-miniarm.dtb
append earlyprintk console=ttyS1,115200n8 root=/dev/mmcblk0p2 rw init=/sbin/init
label kernel-next
kernel /linux-next
fdt /rk3288-tinker.dtb
append earlyprintk console=ttyS1,115200n8 root=/dev/mmcblk0p2 rw init=/sbin/init
クロスコンパイル用マシンにて実行 $ linux-next $ scp arch/arm/boot/zImage arch/arm/boot/dts/rk3288-tinker.dtb 192.168.1.xxx:~/ Tinker Boardにて実行 # cp /home/katsuhiro/zImage /boot/linux-next; cp /home/katsuhiro/rk3288-tinker.dtb /boot/; sync; reboot
ROCK64との違いはCPUがAArch32なので生成されるイメージファイルはzImageであることと、デバイスツリーはrk3288-tinker.dtbであることでしょうか。
カーネルをネットワーク経由で更新する点は同じですが、zImageというファイル名だと元々存在するカーネルと被っているので、リネームしています。
目次: Zephyr
海外で最近話題らしいZephyr OSを動かしてみました。
Linuxに似ている、という説明をどこかで見ましたが、ビルドシステムに関して言えば全く似ていません……。コードは似ているのかもしれませんが、見ていません。
動かし方は Zephyr OSのGetting Started にあります。
Zephyr OSをビルドするためには、いくつかPythonのパッケージをインストールする必要があります。pipを実行しても良いという方はpip3 install --user -r zephyr/scripts/requirements.txt で、依存するモジュールをインストールしてくれるそうです。
私は以前pipでPython環境が壊れて嫌な思いをしたので、apt-getで頑張りました。参考までに下記のパッケージをインストールしています。環境はDebian Testing amd64版です。
python3-colorama python3-yaml python3-pyelftools python3-sphinx-rtd-theme sphinx-rtd-theme-common python3-breathe ninja-build sphinx-common
パッケージが足りない場合の探し方ですけども、パッケージが足りないときはPythonのエラーメッセージにModuleNotFoundError: No module named 'aaaa' こんなメッセージが出ることが多いです。apt-file search aaaaを実行すると、パッケージ名がずらーっと出てきますので、その中からpython3- で始まるパッケージを探してください(Python3モジュールのパッケージはpython3-xxxxという名前が多い)。
Getting Startedの通り
git clone https://github.com/zephyrproject-rtos/zephyr
です。
Getting StartedにはZephyr SDKとやらをインストールせよと書いてありますが、色々大切な部分が全部ぶっ飛んでいてわからなくなっている感じがします。幸いcrosstool-NGにも対応していると書いてあったので、crosstool-NGを使ってみました。
基本的には以前紹介した(2018年7月15日の日記参照)、AArch64 Linux用の環境と同じ手順ですが、./ct-ng menuconfigで設定する項目が多少違います。
$ ./ct-ng menuconfig Target options ---> Target Architecture ---> armにする Bitness: ---> 32-bitにする Toolchain options ---> Tuple's vendor string zephyrにする Operating System ---> Target OS ---> bare-metalにする $ ./ct-ng build [00:34] /
しばらく待つとarm-zephyr-eabiというプレフィクスを持つクロスコンパイラが生成されるはずです。
Zephyr OSのビルドに使用するクロスコンパイラを、~/.zephyrrcに環境変数を定義して指定します。変な作りだなあ……。
export ZEPHYR_TOOLCHAIN_VARIANT=xtools
export XTOOLS_TOOLCHAIN_PATH=/home/katsuhiro/x-tools
注意点としてはXTOOLS_TOOLCHAIN_PATHのx-toolsの後のパスは勝手にarm-zephyr-eabiが使われ、自由に指定できないことです。この点についてはLinuxのCROSS_COMPILE環境変数とは異なるうえ、Zephyrの方が後発にも関わらず退化しています。どうしてこうなった……。
ビルドする前に2手ほど準備が必要です。1手目は環境変数のセットアップです。
cd zephyr source zephyr-env.sh
2手目はcmakeの実行です。
$ cd sample/hello_world $ mkdir build $ cd build $ cmake -GNinja -DBOARD=qemu_cortex_m3 ../ Zephyr version: 1.13.99 -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.2", minimum required is "3.4") -- Selected BOARD qemu_cortex_m3 Parsing Kconfig tree in /home/katsuhiro/share/projects/oss/zephyr/Kconfig Loading /home/katsuhiro/share/projects/oss/zephyr/boards/arm/qemu_cortex_m3/qemu_cortex_m3_defconfig as base Merging /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/prj.conf Configuration written to '/home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build/zephyr/.config' -- Loading /home/katsuhiro/share/projects/oss/zephyr/boards/arm/qemu_cortex_m3/qemu_cortex_m3.dts as base -- Overlaying /home/katsuhiro/share/projects/oss/zephyr/dts/common/common.dts -- Cache files will be written to: /home/katsuhiro/.cache/zephyr -- The C compiler identification is GNU 8.2.0 -- The CXX compiler identification is GNU 8.2.0 -- The ASM compiler identification is GNU -- Found assembler: /home/katsuhiro/x-tools/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -- Performing Test toolchain_is_ok -- Performing Test toolchain_is_ok - Success -- Configuring done -- Generating done -- Build files have been written to: /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build
CMakeを採用しているプロジェクトは大抵、ソースコードのトップディレクトリにあるCMakeLists.txtを指定しますが、Zephyr OSの場合、sample/* の下にあるCMakeLists.txtを使わなければなりません。わからんわ、そんなの。変な作りだな……。
間違ってZephyr OSのトップディレクトリにあるCMakeLists.txtを指定すると、こんなエラーメッセージで怒られます。
$ cmake -GNinja -DBOARD=qemu_cortex_m3 ../ CMake Error at CMakeLists.txt:13 (message): A user error has occured. cmake was invoked with '/home/katsuhiro/share/projects/oss/zephyr' specified as the source directory, but it must be invoked with an application source directory, such as '/home/katsuhiro/share/projects/oss/zephyr/samples/hello_world'. Debug variables: CMAKE_CACHEFILE_DIR: CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.13) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred!
エラーメッセージからは、何が悪いのか全く分かりません……。
ビルドと実行は難しくありません。どちらかというとここまでたどり着くのがかなり面倒くさいです。
$ cd sample/hello_world/build $ ninja [1/103] Preparing syscall dependency handling [98/103] Linking C executable zephyr/zephyr_prebuilt.elf Memory region Used Size Region Size %age Used FLASH: 8604 B 256 KB 3.28% SRAM: 4160 B 64 KB 6.35% IDT_LIST: 120 B 2 KB 5.86% [103/103] Linking C executable zephyr/zephyr.elf $ ninja run [0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m3 qemu-system-arm: warning: nic stellaris_enet.0 has no peer ***** Booting Zephyr OS zephyr-v1.13.0-3162-g73956a398e ***** Hello World! qemu_cortex_m3
何をしているのか全然わかりません。仕方ないのでbuild.ninjaファイルからqemuを実行しているところを発掘してみたら、下記のコマンドを実行しているようです。
$ /usr/bin/qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -vga none -net none -pidfile qemu.pid -serial mon:stdio -kernel /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build/zephyr/zephyr.elf qemu-system-arm: warning: nic stellaris_enet.0 has no peer ***** Booting Zephyr OS zephyr-v1.13.0-3162-g73956a398e ***** Hello World! qemu_cortex_m3
期待される結果が良くわからないんですが、これで動いたと言って良いんだろうか…??
TP-Linkのスマートプラグを利用するにはKASA Smartというアプリをスマホに入れないと微塵も動きません。このアプリの利用規約には同意不可能な条項があって、
法的資格
(中略)お客様は利用にあたりお客様に適用するすべての法律を遵守しなければなりません。準拠法が利用を禁ずる場合はお客様は本サービスを利用することはできません。
ユーザーのコンテンツ
(中略)
2. 世界のあらゆる場所で享受できるユーザーコンテンツに対する全ての人格権を放棄し、そのような権利の主張ができないことを確認する。
と書いてあります。TP-Linkは、ユーザーがフォーラムに投稿した質問、レビュー、回答などを勝手に使うけど、文句言わないでね?と言いたいみたいです。
その主張については同意しますけど、、、
日本では著作者人格権は譲渡できません(著作権法59条)、放棄規定はありませんが、包括的に放棄はできないと考えられており、日本においてTP-Linkの利用規約にYesと答えることはできません。
規約内で矛盾がある場合に、利用者が同意してしまうと、この契約はどうなるんでしょう、無効になるの…?
TP-Linkは中国の会社ですから、この利用規約は中国でもほぼ同じなのではないかと思うんですが、中国って著作者人格権の放棄はできるんですかね?
規約のことは忘れて、スマートプラグを使ってみました。
スマホから電源ON/OFFの指示を送ると、スマートプラグから「カッ!!」というかなり大きめのリレー音がしてうるさいです。今日も元気なことがわかって安心……?
使って初めて知ったのですが、スマホからスマートプラグへの電源ON/OFFの指示は必ずTP-Linkのサーバーに飛んで行くんですね。インターネット接続のできない場所ではスマホのアプリが起動しないため、電源ON/OFF指示ができません。
インターネット接続がなくても、スマートプラグ本体の電源ボタンを押せば電源ON/OFFできますが、そこまで行けるならTinker Boardを直接リセットした方が遥かに早いです。
昔から、ネットワーク対応のACタップは売られていましたが(Pingを打つと電源が落ちる、WebインタフェースでON/OFFできるなど)、いずれも1万円〜数万円の製品です。
従来製品と比較して、サーバーの維持費も追加で必要なはずなのに、大抵のスマートプラグは2,000円〜5,000円で販売されています。機能の割に破格の値段だと思います。
単純に考えると、外出中(=インターネット側から)に、宅内の電源をON/OFFするため、何らかのサーバーを経由しているのでしょう。
嫌らしく考えると、スマートプラグはサーバーを経由させることで、ユーザーの生活情報を強制的に奪えますから、将来に情報が何かに使えることを見込んで、破格の値付けでばら撒いているのでしょう。
Tinker Board上でlinux-nextを実行するとreboot時にハングしてしまい、その後ウンともスンとも言わなくなるので、外部からボードの電源ON/OFFする方法を探していました。考え付いた方法は3つです。
1番目は下手なハンダ付けをして、失敗するとボードが壊れることと、制御用にもう1つボードが要るのは何だかダサいのでやりたくありません。
2番目の線で探していたのですが、USBの給電をON/OFFできる製品って、意外とないですね……。
仕方なく3番目の線で、TP-LinkのスマートプラグHS105を購入しました(メーカーの製品サイト)。Amazonで2,600円です。Wi-Fiが内蔵されている割に、ずいぶん値段が安いですね。
メモ: 技術系の話はFacebookから転記しておくことにした。少し加筆した。
目次: ROCK64/ROCKPro64
年末に喰らったA型インフルエンザのダメージも回復したので、RK3328のI2S1のMCLK(マスタークロック)の設定がおかしくなる問題の追跡を再開しました。
思っていた以上に難しくて理解できず、かれこれ1週間以上費やしてしまいましたが、やっと見えてきました。
ざっくり言えばRockchipのSoCが持つクロック分周器の構成がかなり変わっていることが関係している、と言えるんじゃないでしょうか。良し悪しはさておいて、問題の原因になっています。
再現方法はとても簡単です。48kHz → 44kHzの順で再生すると正常に再生できますが、32kHz → 44kHzの順で再生するとエラーになって再生できません。これだけです。
早速、問題の原因を説明したいところですが、Rockchipのクロックがどのように繋がっているか説明しないと、全く何も意味が分からないと思いますので、軽く説明します。
RK3328やRockchipの 他のSoCは、1〜128分周まで可能なInteger Dividerと、有理数で分周(例えば7/500など、分子、分母は16ビット精度の整数で指定可能)が可能なFractional Dividerの2つを持っています。
RK3328のTRM(Technical Reference Manual)では、前者にi2s1_pll_div、後者にi2s1_frac_divという名前を付けており、Linuxのクロックドライバでは前者にclk_i2s1_div、後者にclk_i2s1_fracという名前を付けています。
媒体 | Integer Divider | Fractional Divider |
---|---|---|
TRM(Technical Reference Manual) | i2s1_pll_div | i2s1_frac_div |
Linux Clockドライバ | clk_i2s1_div | clk_i2s1_frac |
今後はLinuxの名前で表記しますが、接頭辞のclk_ は省きます。
I2S系のクロックはInteger DividerとFractional Dividerの両方を利用可能です。他のハードウェアブロックはInteger Dividerしか使えませんが、UARTとI2SとS/PDIFは両方使えるようです。
PLLと分周器とI2S1の接続は下記のようになっています。
CPLL --> | selector |-----> i2s1_div --+--> | selector |--> I2S1 MCLK GPLL --> | | ,---------------' | | `--> i2s1_frac ----> | |
図からもわかる通り、必要に応じてi2s1_fracは使ったり、使わなかったりします。
例えば48kHz, 32kHzで再生する場合は、GPLL -> i2s1_div -> I2S1の経路が使われます。i2s1_fracは使いません。44kHzで再生する場合は、GPLL -> i2s1_div -> i2s1_frac -> I2S1の経路が使われます。
サンプリング周波数Fsと、正しく再生できているときの各分周器の出力周波数、分周比は下記のとおりです。
Fs | i2s1_div出力 | i2s1_div分周比 | i2s1_frac出力 | i2s1_frac分周比 |
---|---|---|---|---|
32kHz | 8.192MHz | 1/60 | 未使用 | 未使用 |
44.1kHz | 491.52MHz | 1/1 | 11.2896MHz | 147/6400 |
48kHz | 12.288MHz | 1/40 | 未使用 | 未使用 |
ちなみにi2s1_divの入力はGPLLが選択されることが多く、周波数は491.52MHzで固定のようです。CPLL/GPLLの周波数は可変のはずですが、切り替わったところを見たことがありません。まあ、GPLLは今回の話に関係ないから、どうでも良いですけど……。
Linuxのクロックドライバは、セレクタで選択可能なクロック系統(この場合だとi2s1_divとi2s1_frac)全てに対して、同じ目標周波数で設定して、目標に一番近い周波数を出力できるクロック系統を選択する仕組みになっています。
例えば先ほど44.1kHzの再生のときはi2s1_fracが選ばれると言いましたが、実はこのときクロックドライバの裏側では、
この2つの選択肢(※)が提示されており、i2s1_fracの方が目標値に近い(誤差0)ため、i2s1_fracが選択されています。
(※)正確に言うと12MHz clkinもあるので3つの選択肢から選びますが、ここでは説明を省いています。12MHz clkinが選ばれることはほぼありません。
先ほど示した表のとおり、32kHzの再生後はi2s1_divの出力が8.192MHzになります。この状態で44.1kHzを再生しようとすると、クロックドライバはi2s1_fracの出力を11.2896MHzにしようと試みます、しかし…。
今のクロックドライバはi2s1_fracの親にあたるクロック、つまりi2s1_divの周波数が目標の出力周波数11.2896MHzより低いと、設定を諦めてしまう実装になっています。
コードで言うとこの部分です。
//drivers/clk/clk-fractional-divider.c
static long clk_fd_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)
{
struct clk_fractional_divider *fd = to_clk_fd(hw);
unsigned long m, n;
u64 ret;
if (!rate || rate >= *parent_rate) //★★この部分★★
return *parent_rate;
if (fd->approximation)
fd->approximation(hw, rate, parent_rate, &m, &n);
else
clk_fd_general_approximation(hw, rate, parent_rate, &m, &n);
//...
32kHz → 44.1kHzの再生時はrate = 11.2896MHz, *parent_rate = 8.192MHzとなり、★の部分のif文が発動します。これは「i2s1_fracは8.192MHzしか設定できません」という結果を返すことと等しいです。
この結果を受けたクロックドライバの選択肢は下記のようになります。
いずれも目標の11.2896MHzと合いませんが、目標に近いのはi2s1_divと言えます。このためクロックドライバはi2s1_divが最適と判断し、I2S1のマスタークロックが11.214954MHzというおかしな値に設定されてしまいます。
このマスタークロック周波数は、サンプリング周波数44.1kHzの整数倍ではないため、サウンドドライバがエラーと判断してPCM再生を止めてしまいます。
48kHz → 44.1kHzの再生時はrate = 11.2896MHz, *parent_rate = 12.288MHzとなるため、★のif文を突破してfd->approximationの呼び出しに到達します。RockchipのFractional dividerの場合、この関数ポインタはrockchip_fractional_approximation() 関数を指しています。
この関数は変わった処理で、ある条件を満たすと、親のクロックを使うのを諦めて、親の親のクロックを使う処理になっています。
static void rockchip_fractional_approximation(struct clk_hw *hw,
unsigned long rate, unsigned long *parent_rate,
unsigned long *m, unsigned long *n)
{
struct clk_fractional_divider *fd = to_clk_fd(hw);
unsigned long p_rate, p_parent_rate;
struct clk_hw *p_parent;
unsigned long scale;
p_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
if ((rate * 20 > p_rate) && (p_rate % rate != 0)) { //★★目標値が親クロックの20倍より大きく、割り切れないとき★★
p_parent = clk_hw_get_parent(clk_hw_get_parent(hw)); //★★親の親(CPLLかGPLL)を使う★★
p_parent_rate = clk_hw_get_rate(p_parent);
*parent_rate = p_parent_rate;
}
通常ならば、存在するかどうかわからない「親の親のクロック」の存在を仮定しており、Rockchipのクロックトポロジー(PLL -> i2s1_div -> i2s1_frac)と、ハードウェア制約に強く依存した特殊な処理になっていることが伺えます。
しかし、この特殊処理のおかげでi2s1_divの周波数がi2s1_fracにとって扱いづらい変な値に設定されていたとしても、親の親(CPLLかGPLL)の周波数に戻すことができます。
48kHz → 44.1kHzの再生時にi2s1_fracだけでなく、i2s1_divの周波数まで変わってしまっているのは、なんだか不思議だなあと思った方も居るかもしれません。その理由は、この関数が親クロックの周波数目標値を書き換えてしまうから、だったんです。
ここまで読んでいただいている方はほぼゼロだと思いますが……、分周器i2s1_divとi2s1_fracの設定が可能かどうか?どちらを選ぶべきか?を判定する部分は、こんな感じの呼び出し経路になっています。
rockchip_i2s_set_sysclk
clk_set_rate
clk_core_set_rate_nolock
clk_core_req_round_rate_nolock
clk_core_get_boundaries
clk_core_round_rate_nolock // I2S1クロックの設定
clk_core_determine_round_nolock
clk_mux_determine_rate
clk_mux_determine_rate_flags // I2S1手前のセレクタの設定
__clk_determine_rate
clk_core_round_rate_nolock // i2s1_divの設定
clk_core_determine_round_nolock
clk_composite_determine_rate // i2s1_divのセレクタの設定
clk_divider_round_rate // Integer dividerの設定
__clk_determine_rate
clk_core_round_rate_nolock // i2s1_fracの設定
clk_core_determine_round_nolock
clk_composite_round_rate // i2s1_fracのセレクタの設定
clk_fd_round_rate // Fractional dividerの設定
rockchip_fractional_approximation // RockchipのFractional divider固有の設定
何度も同じ関数名が出てきて奇妙に見えると思いますが、目標となるクロック周波数の設定を1ブロックだけで解決できないとき、親クロックに対して再帰呼び出しを行い、親の設定を変更しようとする仕組みになっています。
良くできている素晴らしい仕組みだとは思うのですが…、関数ポインタを使って高度に抽象化されているため、コードを見てもどの関数が呼ばれるのか、もう全く全然わかりません。動作もかなり追いづらいし、デバッグが辛いです……。
Yoctoを使ったプロジェクトをビルドする際に、Gitプロトコルを使わないとアクセスできないリポジトリがあります。
Gitプロトコル(git:// から始まるURLのリポジトリ)は無害なんですけど、大抵の社内プロキシを越えられなくて苦労するので、越え方をメモしておきます。
まずGitのプロキシ設定を行います。この例ではgit-proxyというコマンドを使ってくれと指示しています。
git config --global --add core.gitProxy git-proxy
そんなコマンドはないので、自分で作ります。パスの通った場所、例えば ~/bin/git-proxyのようなファイルを作成して、下記のシェルスクリプトを書いておきます。
#!/bin/sh
exec socat STDIO PROXY:192.168.x.x:$1:$2,proxyport=8080
もちろん別途socatコマンドのインストールが必要です。Debianならapt-get install socatでインストールできます。
最初はnetcatでやってみたんですがダメでした。何でだろ?
< | 2019 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 | - | - |
合計:
本日: