Windows 10 Nov update; stuck at black screen.

In summary;

I have installed Windows 10 Nov update (Buld 10586 / Threshold 2) to Dell Inspiron 11 3147 a few days ago. It was working fine except Cygwin. And then it stuck at black screen after Dell logo before login screen at start up. To make it work again, I had to disable "Windows Driver Foundation - User-mode driver Framework" service.
The service sounds like important/necessary service, and so hopefully Microsoft fix it soon...

[Edit 22/Nov]
I was wondering why it was working fine a few days after update. And I found Windows Update "Cumulative Update for Windows 10 Version 1511 for x64-based Systems (KB3118754)" caused the problem. If KB3118754 is uninstalled, it works fine with the service enabled.
[/Edit]

[Edit 23/Nov]
It happened again. Disable the service seems to be better workaround.
[/Edit]

[Edit 25/Nov]
As in a comment, it needs just touch a screen, then Windows continues booting.
[/Edit]

Long story;

Soon after installed Windows 10 Nov update, I noticed that Cygwin stopped working on my Dell Inspiron 11 3147. But Windows was working fine other than that for a few days. When I got a time to investigate Cygwin problem, I rebooted the pc and it stuck at black screen before login screen. It won't go any further.

Get into safe mode

When it stuck at black screen, there was no mouse cursor. I pressed Windows+p to see external display settings, but nothing happened. I actually connected an external display but it only showed black screen too. And so I had to force shutdown it by pressing power button until LED turned on and then off again.
Because it won't boot into Windows, it needs an install media to boot into Safe mode. But I accidentally found the following way.

• Press F12 to get into Boot options and launch Diagnostics.
• Let it run a while just in case, but you can cancel it memory test.
• Exit Diagnostics. (Then it automatically reboots.)
• Somehow Windows detects a boot problem and you can get into advanced start-up screen.

Disable service

It seemed to be working okay in safe mode. So I guessed the problem was caused by a software. To find a cause, run msconfig.exe, open Services tab and enable services little by little. And finally I found that "Windows Driver Foundation - User-mode driver Framework" service caused the problem.

Clean install

It could be a problem of software combination/conflict and so I clean installed Windows 10 Nov update to confirm it. It installed without a problem, and worked fine for a while but the same problem happened after a few reboot. I did not install any additional software but applied Windows Updates.

So far so good

With the service disabled, I installed my everyday software (anti-virus, Cygwin, Chrome, VLC, Xkeymacs, etc.) and all work fine so far.

Dell XPS L502Xのディスプレイ アップグレード

Dell XPS L502Xのスクリーンの調子が悪くなり、輝度にムラが出てきて、下部2cmくらいが常に白く表示されるようになってしまった。調べてみると、交換用のスクリーンを販売しているLaptop Screenというショップを見つけた。しかも、L502Xは15インチなのに1366x768という残念な解像度なのだけど、フルHDのスクリーンも売っている。
どうやらフルHDのモデルも販売されていたようで、物理的なサイズは全く同じで換装できるらしい。Dellのサポートページによると実際に換装した人もいて成功している。ただしスクリーンとマザーボードを繋ぐフラットケーブルも取り替える必要があるらしい。
必要なフラットケーブルの型番はV73D3といって、残念ながら上記のショップではこのケーブルを販売してなかった。でも、eBayで検索してみると簡単に見つかった。

ということで、注文して物が届いたので、さっそく換装してみた。手順はDellのサポートページからサービス マニュアルをダウンロードできるので、それを参照しながら進めた。

まずは、バッテリーを外して、モジュールカバーを外す。念の為、メモリも外しておいて、あとは無線LANのアンテナ ケーブルをカードから外しておく。

バッテリーを外すとネジと爪が見えるようになるので、そのネジ1本と二つの爪を外すと、パームレストカバー(トップカバー)が外れるようになる。電源ボタンのあたりからぐるっと全周外してから、手前に倒して、2本のフラットケーブルを外す。
そうすると、完全にパームレストを外すことができるようになる。

次はキーボード。まずは上辺にある2つの爪を外して、奥の方へ水平に少しだけスライドさせる。
すると、手前側が持ち上がるようになるので、ちょっと持ち上げて、小さいフラットケーブルを外す。
次に、大きなフラットケーブルを外す。

キーボードを外すと、ディスプレイケーブルが見える。
黒いタブが付いているので、それを引っぱってディスプレイ ケーブルを外す。
ネジも一本外す。

無線カードから外しておいたアンテナ線を引っぱって取り出して、ガイドからも順番に外していく。

スクリーンを本体に固定しているネジを4本外す。ネジを全部外しても、左の写真のように長い足が付いているので、突然倒れて外れたりはしないようになっている。

ベゼルを外す。上方向に無理矢理引っぱって外すのではなくて、ベゼルを水平方向の外側に引っぱりながら上に持ち上げると外れる。
左の写真は外した後の写真で、黒いベゼル側(下)と、灰色のカバー側(上)。

カメラモジュールのケーブルを外す。水平方向に引っぱると抜ける。

ネジを8本外すと (上部2本、下部6本)、パネルがカバーから外れる。1から8まで写真のように番号が振ってある。
パネルを外すだけなら、グリーンのネジは外す必要はない。(ちなみに、このネジを外すとヒンジが外れる。)

パネルからケーブルを外す。テープを剥して、水平方向に引っぱると抜ける。
他にも両面テープで貼り付けてあるので、ゆっくりと剥す。

 ケーブルの見た目は全く同じだけど、一方はV73D3。

別のラベルには、元の方は"HD"、新しい方は"FHD"と書いてあった。

ネジを4本外して、左右のフレームを外す。

後は、新しいパネルと取り替えて、逆の順序で取り付けていくだけ。

ちなみに元のパネルはSamsungのLTN156AT02。(恐らくDellのパーツナンバーは08MN61?)









今までは外部モニターをメインにして使っていて、ほぼデスクノート状態だったけれども、これで外部モニター無しでも色々と使える状態になった。

Intel Edisonでタイムラプス撮影 その2

大体の下準備は済んだので、実際に撮影しながら色々と試してみた。

pkTriggerCord

--resolutionで解像度を変更しても、ダウンロードされるjpegファイルには反映されないバグがあると書かれているけれども、実際に試してみると保存されるjpegは指定した解像度になっている。
ただし、不思議なことにカメラからの転送にかかる時間は解像度に関わらず4秒ちょっとかかる。RAWで撮影するとサイズが大きくなるのでもっと時間がかかるけれども、jpegだと解像度/サイズに関わらず4秒ちょっとかかる。
ダウンロードした後にリサイズでもしているんだろうか? 最大解像度でも最低解像度でも同じ時間がかかるなら、最大解像度で残しておくに越したことはない。それに10秒毎に撮影するなら余裕だし、6秒毎に1時間くらい撮影してみたけれども常に4秒以上5秒未満だった。

ImageMagick (GraphicsMagick)

撮影画像を16:9のアスペクト比にクロップして、さらに1920x1080にリサイズすると、1枚処理するのに20秒くらいかかる。これでは撮影間隔に比べて時間がかかり過ぎる。ImageMagickから派生したGraphicsMagickは処理が早いということなので、試してみると少し短かくなって15秒くらいだった。できれば撮影間隔と同じか短かい時間に抑えたいので、15秒でも遅い。試しにリサイズをやめてクロップだけにしてみると、10秒くらいかかることが分った。
単純に先頭と後尾の部分を読み飛ばして16:9にクロップするプログラムを、libjpegを使ってCで書いてみたけど、IM/GMと同様に10秒くらいかかった。(同じライブラリを使用しているのだから、当然の結果か?) 何とかならないかなぁとlibjpegのマニュアルを読んでいたら、デコードの段階でスケール(scale_numとscale_denom)を変更すると非常に早くなると書いてあった。K20Dの最高解像度は4672x3104なので、1/2にしても1920x1080よりは大きい。そこで1/2のスケールでデコードしてみた。すると3秒まで縮んだ。

OpenCV

自作のクロップ プログラムが出力したファイルをImageMagickでリサイズしてもいいけれども、ファイルI/Oが増えることになるし、クロップと同時にリサイズもやってしまうことにした。OpenCVライブラリが既にパッケージになっていたので、opkgでインストールして利用した。リサイズにかかる時間は実行時間にほとんど影響がないくらい速く、リサイズのコードを追加した後でも3秒くらいのままだった。これなら撮影間隔未満なので十分と言える。
余談になるけれど、libjpegとOpenCVではメモリに展開したイメージデータの構造が同じなので、そのまま受け渡しができた。ただしRGBデータの順序が違っている。本来ならば、データを受け渡しする際に順序を揃えなければならないし、順序を変更するためのメソッドも用意されていた。けれども、リサイズだけなら色情報は関係ないんじゃないかと思い、順序の変更なしにリサイズ処理をしてみたら、予想通り問題無くリサイズできた。

inotify-tools

pkTriggerCordが撮影して保存が完了するのに合わせて、クロップ/リサイズ プログラムを走らせる必要がある。inotifywaitというコマンドがちょうどその用途に合っているのだけれども、Intel Edisonにはインストールされておらず、opkgにもなかった。
inotifyの仕組み自体はカーネルの機能らしいので、inotify-toolsをgitからcloneしてインストールしてみた。インストールは、
# ./autogen.sh
を実行するとconfigureが生成されるので、
# ./configure
を実行して、あとはmakeとmake installするだけ。
テストしてみたところ問題無く動いている。

これで、撮影しながら同時に画像変換もできるようになった。

Intel Edisonでタイムラプス撮影 その1

以前、ストップモーション ムービーを作って遊んだ時は、ノートPCを使ってテザー撮影したけれども、タイムラプスの撮影をする時は撮影画像をその場でチェックするわけじゃないから、Intel Edisonでも十分可能だろうということで試してみた。

pkTriggerCord

カメラはこういう時の遊び用に使っているPentax K20Dなので、リモートコントロールのソフトにはpkTriggerCord (ver. 0.82.04)を使用した。

ソースをダウンロードして、GUIはいらないので、

# make cli

# make install

で、あっさりと完了。

OTGケーブルを経由してK20Dを繋いだら、とりあえず1枚撮影してみる。

# pktriggercord-cli --green -o test.jpg

画面のないEdison上では画像を確認できないので、PCに転送して撮影できていることを確認。

簡単にタイムラプスのテストもしてみた。

# pktriggercord-cli --frames 10 --delay 10 --green -o test

上記のコマンドで10秒毎に10枚撮影してくれる。画像の転送時間を考慮して待ち時間を調整してくれるので、例えば転送に4秒かかったら6秒待機して、正確に10秒毎に撮影をしてくれる。

ImageMagick

ちょうどpkTriggerCordのサイトにタイムラプス撮影の解説もあったので、それに従ってクロップとリサイズもEdison上でやってしまうことにした。

ImageMagick (ver. 6.9.2-4)のソースをダウンロードして、

# ./configure

# make

いくつか警告が出たけれども、エラーはなく終了。

先程撮影した画像でテストしてみると、

# identify test.jpg

identify: no decode delegate for this image format 'test.jpg'

と言われてしまった。

# identify -list configure | grep DELEGATES

で確認してみると、確かにjpegがない。

jpegのライブラリがないのが原因らしいので、インストールする。opkgで探してみると、
# opkg list | grep jpeg
libjpeg8とlibjpeg-devというのが見つかったので、インストールしてみた。

# opkg install libjpeg8

# opkg install libjpeg-dev

そうしたら、再度

# ./configure

してから、

# make

する。そうすると、
# identify -list configure | grep DELEGATES
DELEGATES bzlib mpeg jpeg xml zlib
となって、identify コマンドもきちんとjpeg画像の情報を表示してくれるようになった。

FFmpeg

最後はFFmpeg。静止画から動画の変換はEdisonでしなくてもいいかなと思ったけれども、せっかくなので挑戦してみた。

ソースはgitからクローンする。

# git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg

(git クライアントは# opkg install gitでインストールできる。)

# ./configure

を実行すると、prコマンドがなくてエラーになる。prコマンドはcoreutilsに含まれているので、

# opkg install coreutils

でインストール。

すると今度はyasm/nasmがないとエラーがでる。

yasm/nasm not found or too old. Use --disable-yasm for a crippled build.

メッセージの通り、--disable-yasmをつけてやり直し。

# ./configure --disable-yasm

# make

すると、makeの途中でエラーが出た。

libavcodec/x86/cabac.h:192:5 error: 'asm' operand has impossible constraints

gccのインライン アセンブラのエラーらしい。Edisonにインストールされているgccはver. 4.9.1。 NASM (ver. 2.11.08)をインストールしたら何か変るかと試してみたけれども、同様のエラーがでる。

該当のヘッダを使用しているソースを見てみると、H264のデコード関連らしい。今回の目的(静止画から動画への変換)には必要のない機能なので、その機能を除外してmakeしてみた。
# ./configure --disable-decoder=h264
そうすると、エラーになる箇所はスキップしてビルドできた。

ついでなので、色々と試してみたところ、--disable-asmまたは--disable-optimizationsを指定するとH264のデコード機能を生かしたままビルドできた。でも、実際に計測はしていないけれども、恐らく他のコーデックのエンコード/デコード性能も落ちると予想できるので、今回はH264のデコードを諦めることにした。

さらについでに、H264のエンコードをサポートしたい場合は、x264のライブラリをopkgでインスールして、--enable-libx264を指定すれば良いみたい。(このスレッドを参考にした。)
# opkg install libx264-133
# opkg install libx264-bin
# opkg install libx264-dev
# opkg install libx264-staticdev
最終的にconfigureのオプションは以下のようになった。
# ./configure --disable-decoder=h264 --enable-libx264 --enable-gpl
あとはmakeして完了。(ちなみに、ビルドに2時間くらいかかる。)
# ffmpeg -codecs | grep 264
.EV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (encoders: libx264 libx264rgb)
H264のエンコードをサポートしたffmpegのできあがり。

Intel Edison; clone

I wanted to clone/copy a reference Edison board to multiple Edison boards. Maybe, the proper way of doing this is to build from source code with a customised configuration. But I also wanted to find out an easy way of backup/restore. And I came up with the following steps.

1. Preparation 1: Bootable SD card.
2. Preparation 2: Make a reference Edison
3. Enable resize-rootfs.service.
4. Boot from SD card.
5. Mount rootfs and check how much used.
6. Create a disk image and mount it.
7. Copy files from rootfs@emmc to the mounted disk image.
8. Unmount the disk image and copy it to a PC.
9. Rename the disk image file to edison-image-edison.ext4 and replace the same name file in unzipped firmware directory.
10. Run flashall against a target Edison board.

Preparation 1

It needs bootable SD card to safely copy rootfs partition. See this post for detail.

Preparation 2

Install required software, enable/disable services, add user account, etc.

Enable resize-rootfs.service

When create a disk image file, it need not copy empty blocks. So a disk image file is smaller than rootfs partition's size. After a target's rootfs partition is overwritten with a disk image, it needs to extend to an actual size. It happens when flashing by flashall/ota method too, so that there is already a service that runs only once at the first boot. Enable this service before boot from SD card. But even if you forget this, you can just run resize2fs command to extend rootfs partition. It can be done on live file system.

# systemctl enable resize-rootfs
Then reboot from SD card.
# reboot from_sdcard

Mount rootfs partition in eMMC and check size

After boot from SD card, mount rootfs partition in emmc and check its size.

# mkdir /mnt/emmc

# mount /dev/mmcblk0p8 /mnt/emmc

Run df and see how much used. In my case, 500MB is enough.
# df -h | grep /mnt/emmc
Filesystm      Size   Used Available Use% Mounted on
/dev/mmcblk0p8 1.4G 471.0M    889.0M  35% /mnt/emmc

Create a disk image and mount

The following command creates 512MB (512KB * 1024) disk image file (edison-rootfs.ext4). If you need bigger space, modify count=1024.

# dd if=/dev/zero of=edison-rootfs.ext4 bs=512K count=1024

# mkfs.ext4 -F -L rootfs edison-rootfs.ext4

# mkdir /mnt/image

# mount -o loop edison-rootfs.ext4 /mnt/image

Copy from eMMC to disk image

It is optional, but you can delete journal files before coping.

# cd /mnt/emmc/var/log/journal

# rm -rf *

It is also optional. But if a copied Edison is used somewhere else, it would be better to delete your Wifi information.

# cd /mnt/emmc/etc/wpa_supplicant
# cp wpa_supplicant.conf.original wpa_supplicant.conf

Now, copy all files.
# cp -a /mnt/emmc/* /mnt/image/
It seems to be better to use rsync because cp copies hard linked files as individual file. But then it needs to install rsync from opkg.
# opkg install rsync
# rsync -rlH /mnt/emmc/ /mnt/image/

Unmount and copy

# umount /mnt/image

# umount /mnt/emmc

Copy edison-rootfs.ext4 to a PC.

Clone

To make a clone, rename edison-rootfs.ext4 to edison-image-edison.ext4 and replace the same name file in a unzipped firmware directory. Then run flashall script and connect a target Edison.

(Strictly speaking, it is not a complete clone. It only copies rootfs. You might want to copy home and u-boot-env0 partitions too. To make more perfect clone, it needs to copy factory partition too. (That partition contains serial number and Bluetooth MAC address.))

Intel Edison; boot from SD card.

There is very detailed post in Intel's forum. Basically I just follow the instruction in that post.
https://communities.intel.com/thread/61048

Prepare SD card

In my case, out-of-box Edison (edison-weekly_build_56_2014-08-20_15-54-05) did not have mkfs.ext4 command. But in the latest firmware (weekly-159), the command exists. And so you do not need a Linux PC to format SD card with ext4.

Copy edison-image-edison.ext4 in a zipped firmware file to Edison using scp command.
$ scp edison-image-edison.ext4 root@192.168.2.15:edison-image-edison.ext4
Or copy the file to a SD card.

Insert SD card to Edison. If you copied the file to SD card, then copy the ext4 image file to somewhere else as SD card will be formatted.
# cp /media/sdcard/edison-image-edison.ext4 /home/root/

Find SD card's device name
# mount | grep sdcard
In my case, it is /dev/mmcblk1.

Format it with ext4.
# umount /media/sdcard
# mkfs.ext4 /dev/mmcblk1p1

Mount ext4 image file and SD card.
# mount -o loop /home/root/edison-image-edison.ext4 /mnt
# mount /dev/mmcblk1p1 /media/sdcard

Copy files.
# cp -a /mnt/* /media/sdcard/

Configure U-Boot variables

I wrote a shell script based on the forum post.

#!/bin/sh

fw_setenv mmc-bootargs 'setenv bootargs root=${myrootfs} rootdelay=3 rootfstype=ext4 ${bootargs_console} ${bootargs_debug} systemd.unit=${bootargs_target}.target hardware_id=${hardware_id} g_multi.iSerialNumber=${serial#} g_multi.dev_addr=${usb0addr}'

# SD card

sdcard=`mount | grep sdcard | awk '{print $1;}'`
if [ "$sdcard" == "" ] ; then
  echo Insert SD card and try again.
  exit
fi
fw_setenv myrootfs_sdcard $sdcard

# eMMC

emmc=`/usr/sbin/fw_printenv uuid_rootfs | sed 's/uuid_rootfs=\(.*\)/\1/'`
fw_setenv myrootfs_emmc PARTUUID=$emmc

# Can use those at boot> prompt too.

fw_setenv do_boot_emmc 'setenv myrootfs ${myrootfs_emmc}; run do_boot'

fw_setenv do_boot_sdcard 'setenv myrootfs ${myrootfs_sdcard}; run do_boot'

# reboot from_sdcard or from_emmc

fw_setenv do_handle_bootargs_mode 'run do_preprocess_bootargs_mode; if itest.s $bootargs_mode == "ota" ; then run do_ota; fi; if itest.s $bootargs_mode == "boot" ; then run do_boot; fi; if itest.s $bootargs_mode == "flash"; then run do_flash; fi; if itest.s $bootargs_mode == "from_sdcard"; then run do_boot_sdcard; fi; if itest.s $bootargs_mode == "from_emmc"; then run do_boot_emmc; fi; run do_fallback; exit;'

The script modifies do_handle_bootargs_mode variable too. With this modification, you can boot from SD card by "reboot from_sdcard", or from eMMC by "reboot from_emmc".

Intel Edison; flashing out-of-box Edison

There are two (or more?) ways to flash Edison.

1. Phone Flash Tool (GUI) or flashall.bat/flashall.sh (CUI)
2. reboot ota command or run do_ota at Boot prompt.

But it cannot use "reboot ota" method on out-of-box Edison. In my case, oob Edison's version is

root@edison:~# cat /etc/version 

edison-weekly_build_56_2014-08-20_15-54-05

And if you run reboot ota, it fails. The reason is in ota_abort_reason U-boot environment variable.

root@edison:~# fw_printenv ota_abort_reason

ota_abort_reason=Partition rootfs too small for edison-image-edison.ext4 

Oob Edison's partition layout looks like this.

Number Start End Size File system Name Flags 

 1 1049kB 3146kB 2097kB       u-boot0 

 2 3146kB 4194kB 1049kB       u-boot-env0 

 3 4194kB 6291kB 2097kB       u-boot1 

 4 6291kB 7340kB 1049kB       u-boot-env1 

 5 7340kB 8389kB 1049kB ext2  factory 

 6 8389kB 33.6MB 25.2MB       panic 

 7 33.6MB 67.1MB 33.6MB fat16 boot 

 8 67.1MB 604MB   537MB ext4  rootfs 

 9  604MB 1409MB  805MB       update 

10 1409MB 3909MB 2500MB ext4  home 

To compare, this is a partition layout after flashing to the latest firmware (weekly-159).

Number Start End Size File system Name Flags 

 1 1049kB 3146kB 2097kB       u-boot0 

 2 3146kB 4194kB 1049kB       u-boot-env0 

 3 4194kB 6291kB 2097kB       u-boot1 

 4 6291kB 7340kB 1049kB       u-boot-env1 

 5 7340kB 8389kB 1049kB ext2  factory 

 6 8389kB 33.6MB 25.2MB       panic 

 7 33.6MB 67.1MB 33.6MB fat16 boot 

 8 67.1MB 1678MB 1611MB ext4  rootfs 

 9 1678MB 2483MB  805MB       update 

10 2483MB 3909MB 1426MB ext4  home 

reboot ota command cannot change a partition layout, because the command refers files in update partition and rootfs partition is followed by update partition. If extend rootfs partition size, it destroys update partition.

On the other hand, flashall command does the following steps.

1. Flash u-boot0/1 and u-boot-env0/1 partitions.
2. Reboot.
3. Flash rootfs partition.

At the second reboot step, U-boot overwrites a partition table using updated partitions variable at the first step.

root@edison:~# fw_printenv partition

partitions=uuid_disk=${uuid_disk};name=u-boot0,start=1MiB,size=2MiB,uuid=${uuid_uboot0};name=u-boot-env0,size=1MiB,uuid=${uuid_uboot_env0};name=u-boot1,size=2MiB,uuid=${uuid_uboot1};name=u-boot-env1,size=1MiB,uuid=${uuid_uboot_env1};name=factory,size=1MiB,uuid=${uuid_factory};name=panic,size=24MiB,uuid=${uuid_panic};name=boot,size=32MiB,uuid=${uuid_boot};name=rootfs,size=1536MiB,uuid=${uuid_rootfs};name=update,size=768MiB,uuid=${uuid_update};name=home,size=-,uuid=${uuid_home}; 

Just for reference, oob Edison's partition variable:

partitions=uuid_disk=${uuid_disk};name=u-boot0,start=1MiB,size=2MiB,uuid=${uuid_uboot0};name=u-boot-env0,size=1MiB,uuid=${uuid_uboot_env0};name=u-boot1,size=2MiB,uuid=${uuid_uboot1};name=u-boot-env1,size=1MiB,uuid=${uuid_uboot_env1};name=factory,size=1MiB,uuid=${uuid_factory};name=panic,size=24MiB,uuid=${uuid_panic};name=boot,size=32MiB,uuid=${uuid_boot};name=rootfs,size=512MiB,uuid=${uuid_rootfs};name=update,size=768MiB,uuid=${uuid_update};name=home,size=-,uuid=${uuid_home};