2010-09

2010-08←　→ARM　armon　stm32f103　ＡＶＲ／ＰＩＣ両用ライター　usbシリアル変換 　usbキーボード 　簡易ロジアナ、赤外線リモコン信号観測

９月：秋？†


もしくは秋の月：秋月


↑

先月のまとめ†

  • ARM用のHID Bootloaderをでっちあげてみる。--- armon、LPCXpressoの項を参照のこと。
    • 制覇した基板は、STM8S-Discovery,CQ-STARM,STBEE,STBEE-Mini、それから、LPC1343:LPCXpresso,ARMマイコン パーフェクト学習基板 TRZ1010N。


今月の目標

↑

Netduino†

スイッチサイエンス

Netduino本家

  • http://www.netduino.com/netduino/specs.htm 
     ● Atmel 32-bit microcontroller 
 ● Speed: 48MHz, ARM7 
 ● Code Storage: 128 KB 
 ● RAM: 60 KB
  • 実はC#に興味はないので、普通にCで動かせるなら１枚くらい持っててもいいかな。
  • 容量、CPUクロック的にはごく普通で、命令セットもごく普通のARM7(ARMとThumbの両方OK)。
    • 嘘：AT91SAM7x512なので、Flash512K,RAM128Kらしい。
    • で、何で128KしかRAMがないのに、Code Storage 128K + RAM 60Kなんだろう？？？
    • Code StorageはもしかしてFlash側に書くのかな？
  • Arduinoと基板サイズなどが互換なのでシールドが使いまわせるのではないかと。





↑

コモドール64型PC、ホリデーシーズンに発売†

  • 当然VICエミュレータとかROMとか付けて欲しいところ。





↑

LPC1343:とりあえず、BOOT-ROMの逆アセンブルなどやってるんだけど・・・†

  • ARM(Thumb2)のアセンブラソースなんて、読めたもんじゃないね。まるでSH2だ。
  • こっそり貼っとく。
  • で、たぶん、LPC1343 users manualのメモリーマップに書いてある、 
    flash controller (0x4003_c000)
    を叩いている箇所を探せばいいのだろうとあたりをつけてみたけれど
  • LPCのヘッダーには、そのアドレス定義も、構造体定義も存在していない。
  • users manualには 
    Table 56. Flash configuration register (FLASHCFG, address 0x4003 C010) bit description
Bit Symbol Value Description Reset  value
1:0 FLASHTIM Flash memory access time. FLASHTIM +1 is equal to the 
   number of system clocks used for flash access.
10
00 1 system clock flash access time (for system clock frequencies of up to 20 MHz).
01 2 system clocks flash access time (for system clock frequencies of up to 40 MHz).
10  3 system clocks flash access time (for system clock frequencies of up to 72 MHz).
11 Reserved.  
31:2 - - Reserved. User software must not change the value of 
these bits. Bits 31:2 must be written back exactly as read.
<tbd>

と、だけしか書かれていない。

  • しかしBOOT-ROMのファームには4003_c000（未定義箇所：FLASHCFG=4003c010なので・・・）を参照している箇所が４つくらいあるので、ここをどうかしているのではないかと・・・（未確認）




↑

LPC1343:解析の続き†

  • もしかしたら、LPC2xxxのFlash書き込み手順との類似性があるのではないかと気づく。
  • LPC2388のUMを読んでみる。
  • LPC2388のBOOTROMにはUSB接続機能はない。
  • シリアルブートの機能はある。これは類似性がある。
  • シリアルブートではなく、ユーザーコードからFlashプログラミングを行うIAPという機能があった。


  • それはLPC1343にもあったのだ。なんで気づかなかったのだろう。
  • The IAP routine resides at 0x1FFF1FF0 location and it is thumb code.
  • The IAP function could be called in the following way using C.
  • Define the IAP location entry point. Since the 0th bit of the IAP location is set there will be a change to Thumb instruction set when the program counter branches to this address.
  #define IAP_LOCATION 0x1fff1ff1
  • Define data structure or pointers to pass IAP command table and result table to the IAP function: 
      unsigned long command[5];
  unsigned long result[4];
  typedef void (*IAP)(unsigned int [],unsigned int[]);
  iap_entry=(IAP) IAP_LOCATION;
  iap_entry(command, result);
↑

つまり、1fff1ff1番地を呼べと。†

Table 308.IAP Command Summary
----------------------------------------------
IAP Command           |Command Code
Prepare sector(s) for write operation 50
Copy RAM to flash      51
Erase sector(s)        52
Blank check sector(s)  53
Read Part ID           54
Read Boot code version 55
Compare                56
Reinvoke ISP           57
Read UID               58
----------------------------------------------
  • command[],result[]はともに整数の配列（可変長）で、各配列の先頭アドレスを引数として与えるらしい。
↑

RTFM†

  • つまり、マニュアルを読めということ。
  • わざわざFlash Programing codeを書くことはない。BOOTROMに呼び出しエントリーがちゃんと用意されているのだ。
  • Flash書き込みに必ずBOOT-ROMを経由する理由のひとつは、Flashの消去や書き込み中はFlashへアクセス出来ないから（おそらく異なるページにいてもだめ）なのだろう。




↑

LPC1343:armon移植完了†

  • FlashのERASEと書き込み、それから2000番地のユーザープログラム起動まで可能になった。
  • 意外と簡単だった。
  • たぶんLPC2388用のarmonも同じ手法で作れるような気がした。

read more: LPCXpresso

デバッグのこつはこうだ。

  • アプリモードを有効にする。
  • userコマンドでFlash書き換え関数のテストが出来るようにしておく。
  • BOOT-ROMのリターンコードをprint出来るようにしておく。
  • テストを実行する。
  • リターンコードを確かめる。
  • Flashがどう書き換わったかを確かめる。

全部armon内で実行できる。

  • ジャンパーを切り替えてfirmware.binを書き込むのが一番面倒だった。（USBドライブ認識が遅いし不安定）
↑

ToDoみたいなやつ†

書いとかないと忘れるしたぶんやらない。

  • STM32へのバックポート---済み
  • STBEEの512kサイズに対応---済み
  • アプリモードのHIDmonが動いていたらbootmodeに戻してファーム書き換えする処理---済み
  • bootコマンドでのシステムスタックの初期化
  • pollモードの実装
  • verify高速化
  • LPC1343のusb disconnect処理---うまく行かない・・・。
  • バスエラー対策---host側でホワイトリストを持つ。
  • ・・・




↑

PS3:変なJailBreakが流行っているという噂†

mobilehackerz

PSGroove(git)

PSJailbreak reverse engineered, it's actually a unique exploit

PSJailbreak Exploit Reverse Engineering

2ch

苺も大迷惑だな

  • 使い道がほとんどないと思われていたAT90USBが脚光を浴びるなんて・・・


  • で、このpsjailbreakのopensource cloneであるpsgrooveの正体はなんなんだ？
  • HUB Device ????

EMUonPSP(08/27)

引用

(1)PS Jailbreakで使われているチップはPIC18F44で、ソフトウェア的にUSBデバイスを実現可能
(2)PSJailbreakは6ポートUSBハブとしてPS3からは見える。更にそのエミュレーションされた6ポートのUSBハブへ
　　繋がったり切れたりするUSBデバイスもエミュレーション出来る
(3)そのうちの一つのデバイスはSCEIのジグツールのIDを持っているため、PSJailbreakを接続すると
　　PS3では6ポートUSBハブが繋がり、その先にはジグツールが繋がっているように見える(エミュレートされたUSBデバイス)
(4)PS3はUSBデバイスが接続された時、USBデバイスのコンフィギュレーションディスクリプタ(設定データ)を読み込む
(5)PSJailbreakがエミュレーションしているUSBデバイスのコンフィギュレーションディスクリプタはそのサイズが大きく、データの中身は
　　PPC向けのコード+exploitなデータで構成されている
(6)ジグツールが短期間(数ms位)接続された後、暗号化されたデータがジグツールに転送される(exploitを利用してPPC(CELL)に
　　先にロードしたコンフィギュレーションディスクリプタ中のPPC用のコードを実行させて実現している?)
(7)更に数ms後、PSJailbreakは64byteのデータをPS3に返す(ジグツールとして認識されるためのデータ)
(8)その後エミュレートされていたUSBデバイスは全部外され、PS3はジグツールが接続された時と同じ状態になっている

ユニークだが

  • また面倒くさいことを!

PIC18F2550でも出来るらしい

↑

LPC1343:クロックアップに挑戦だ!!†

  • 秋なので、無謀なことを試みてみる。
  • lpc-armonを起動。
  • アプリケーションモードに切り替え（あらかじめmain-2000.hexをbootloaderで書いておく） 
    ARM>boot 2000
ARM>q
  • 再度、立ち上げて、ＬＥＤが点滅することを確認。

次。

  • Table 55.PLL configuration examples
    PLL input frequency(Fclkin)Main clock(Fclkout)MSEL bitsM dividerPSEL bitsP dividerFCCO clock
    12 MHz72 MHz001016012288 MHz
    12 MHz48 MHz000114012192 MHz
    12 MHz36 MHz000103104288 MHz
    12 MHz24 MHz000012104192 MHz
  • で、MSEL,PSELは40048008番地にある
          |0|PSEL| MSEL|
4004_8008 |7|65  |43210|

早速、MSEL,PSELの値を確認、上記Table55の通り。

ARM> ew 40048008
40048008 25
  • 現在12MHz x 6 = 72MHz

では、書き換えてみる。

ARM> ew 40048008 26　＃12MHz x 7 = 84MHz
ARM> ew 40048008 27　＃12MHz x 8 = 96MHz
ARM> ew 40048008 28　＃12MHz x 9 =108MHzこれはＬＥＤが点滅しない。
ARM>  ＃無反応になる。
^Cバッチ ジョブを終了しますか (Y/N)? y
  • 結局、96MHzまでしかクロックアップ出来ない。
  • ただし、96MHzでの耐久テストは行っていないので、96MHzでちゃんと動くとは言えない。ＬＥＤの点滅は行われているようだ。
  • LPCXpresso,TRZ1010Nともに同じ結果だった。
  • 108MHzは、内蔵のクロック(FCCO)がその４倍である432MHzで発振しなければならないがそれは無理（320MHzまでしか行かないらしい）
  • なので、PSEL=00(/2モード)にすべきなのだが、PSEL=00ではMSELを幾つにしても無反応になるようだ。


こんな風に、armon(HIDmon)の面白いところは、思い立ったらすぐにポートの値を書き換えて気軽に試せる点だ。

  • 新たにソースを起こしたり、コンパイルしたりする必要がないのが楽。



↑

LPC1343:クロックダウンに挑戦だ!!†

  • こんどは遅いほうをやってみた。
    PLL input frequency(Fclkin)Main clock(Fclkout)MSEL bitsM dividerPSEL bitsP dividerFCCO clock
    12 MHz72 MHz001016012288 MHz
    12 MHz48 MHz000114012192 MHz
    12 MHz36 MHz000103104288 MHz
    12 MHz24 MHz000012104192 MHz
  • ＬＥＤの点滅速度で、実際のＣＰＵ動作クロックを確かめるため、アプリケーション側に切り替える。 
    ARM>boot 2000
ARM>q

そして、MSEL,PSELの値を確認、上記Table55の通り。

ARM> ew 40048008
40048008 25
  • 現在12MHz x 6 = 72MHz
  • 遅くしてみる。 
    ARM> ew 40048008 23 ＃12MHzx4=48MHz FCCO=192MHz
ARM> ew 40048008 43 ＃12MHzx4=48MHz FCCO=384MHz(規格外)
ARM> ew 40048008 42 ＃12MHzx3=36MHz FCCO=288MHz
ARM> ew 40048008 41 ＃12MHzx2=24MHz FCCO=192MHz
ARM> ew 40048008 61 ＃12MHzx2=24MHz FCCO=384MHz(規格外)
ARM> ew 40048008 60 ＃12MHzx1=12MHz FCCO=192MHz
ARM> ew 40048008 40 ＃12MHzx1=12MHz FCCO= 96MHz(規格外)
  • 48MHzは素直にTable55の値のほうが良いかも。
  • 12MHzはXtalと同じ周波数にすればいいので、PLLを使わずにスルーにしたほうが良いかも。
  • だけど、FCCO=156MHz〜320MHzを外れても動いてるなぁ。
  • PSEL=00では一切動かないのは何故だろう。



↑

LPC1343:再度クロックアップに挑戦†

  • こんどは、FCCOの変化が起きない様に騙す手法を試してみた。
  • 最初の手順は同じ。

MSEL,PSELの値を確認、上記Table55の通り。

ARM> ew 40048008
40048008 25
  • 現在12MHz x 6 = 72MHz
  • 一回遅くしてみる。 
    ARM> ew 40048008 23 ＃12MHzx4=48MHz FCCO=192MHz(PSEL=2*2)
  • まず、こうすることで、FCCO（内蔵PLL発振）の周波数を192MHzに引き込んでおくのだ。
  • 次に 
    ARM> ew 40048008 07 ＃12MHzx8=96MHz FCCO=192MHz(PSEL=1*2)
  • で、PSELの分周比を1/2に減らして、MSELの分周比を２倍(x4からx8へ)に。同時に切り替える。

こうすると、FCCOの周波数は変わらないので、PLLの引き込みで大幅な周波数変更が起きない

  • つまり、過渡的にに「動作不能なPLL周波数」になりにくくなる。
  • 96MHzで動くようだ。
  • 耐久テストは行っていないので、安定して96MHzで動くわけではないが、こんどはFCCOの発振周波数は規格内のままオーバークロッキングすることが出来た。




↑

例の300MHzのARM9搭載ノート風PDA:14,970円の実物を見てきた。†

近所のパソコン屋に実物があった。

  • http://akiba-pc.watch.impress.co.jp/hotline/20100619/ni_cnote7.html
  • 日本語キーボードだったので買わない。
  • そのまえにOSがWindowsCEだったので要らない。
  • ubuntuとかandroidに載せかえられる可能性があるなら（自力では嫌!!）、買ったかもしれない（但し英語キー限定で）

７９９９円の似たようなWinCE機をAndroid化している人は居るらしい。

こんなもんが作れるんだったら、いっそのこと玄箱Proみたいに、ＯＳ移植キットだけ入れて、あとはマニアさん達で 好きなＯＳ入れてくださいねというスタンスで売ればいいのにとか思った。


ググっていたら、別の残念なネットブックが引っかかった

↑

lyumobook†

スーパーのイオンで１万円〜１万５０００円程度で売られていたらしい（過去形）


バラしている人も居る。

残念な点はLinuxのディストリビューションが中華系でダメダメなところだ。

  • ARMでなくMIPSなところも残念だが。
  • これもユーザーランドぐらい自由に差し替えが効く様にさえしておいてくれれば、マニア達の格好の餌食になれるのにな。

EPC 700で遊ぶ


結局のところNetBookもSmartBookも、使えない試作品の屍累々という状況でAppleだけの一人勝ちになっているのが実情だ。

  • うん、iPadが512MBメモリー、16GBストレージ、1GHz Cortex-A8という状況において、これ(128MB,2GB,366MHz)はないよな。
  • たしかに１０年前のPCより低性能だ。




↑

LPCXPresso:こんどはLinux？†

  • LPCXPresso(LPC3154+LPC1343基板：秋月にて2800円)のLPC3154側の回路図発見!
  • 上のHPの「Board Schematics (in pdf)」というところにもろに載っている。
  • いやーBGAパッケージなので、ほんとどうしようかと思ってたところだ。
  • おあつらえむきに74VCTまで載っているしUSBはhighSpeedだし。超高性能なJTAGライターになりうる。


  • それから、LPC31xx/32xx用のLinuxを扱っているサイトがあった。
  • LPC3154の内蔵RAMは192kBしかないので、外付けDRAMくらいは必要そうだが、bootloader関連の情報を漁るには良いかも。

つまり。

  • LPCXpressoは一粒で２度美味しいと。




↑

FPGAで作るCRAY-1†

CRAY-1が、１つのzipファイルに。

  • cray1.zip
  • おれにもひとつクレイ。




↑

LPC3154:　LPC313x USB gadget support in Uboot†

LPCLinux

  • LPC3154(LPCXPressoのLPC-Link側CPU)はFlashやSD/MMC,シリアルEEPなどを実装 していない。
  • かわりにDFU(DeviceFirmwareUpgrade)というUSB.orgで定義されている機能を使って パソコン側から毎回ファームウェアを流し込んで起動するのだ。
  • 一応セキュリティが掛かっているっぽい。詳細はNXPのuser.manual.315x.pdf などを見ると書いてある。
  • 上記サイトではDFUに対応した(Linuxをブートさせるための)USBブートローダーを配布しているらしい。
    • あーでもホストＯＳはWindowsではなくLinuxだな。
  • LPC3154にはハードウェアAES(たぶん128)デコーダーが入っているらしい。凄いな。ハードウェアの量的には XORとテーブル引きが並んでいるだけだが、段数が（たぶん10段くらい）あるのでソフトウェア実装だと遅くてかなわん。
  • 某ゲーム機とえらいちがいだ。
  • USB2.0がHighSpeedだし、MMUが載っているし、SDRAMインターフェースがあるので、メモリーさえ載せればLinuxだろうが WindowsCEだろうが動くらしい。（WindowsCEの場合は液晶とかつけないとだめか。）
  • CPUクロックは180MHz＠1.2V。

http://www.lpclinux.com/LPC313x/LPC313xGettingstartedELDK

  • このページの解説に従って、u-bootをDLし、パッチをあて、(gcc WinARM on Linuxで)ビルドして、ddして、unsmgdrした。
  • 結果、init-u-boot.romを得た。
  • この.romをDFU-Utilsでデバイスに転送すればLinuxが立ち上がる（？）のかな。（いや違うと思う）
  • u-bootのほかに、もっと軽量のブートローダー(APEX)があり、LPC313xパッチも存在しているけれど、
  • 残念ながら、USBブートの機能だけ欠落している（その他のシリアルとかSD/MMCとかFlashなどのブートはサポートされている）
  • 結局u-bootしか選択肢がないというわけか。

DFU-UtilがLinuxコマンドラインでしか動作しないので、

  • Linuxの動くネットブックとか欲しくなった。




↑

Netduino , uboot , ...†

ubootを、ubuntu10.04TLSで動かそうとしてみた。

  • ubuntuでは、OpenMokoのdfu-utilをapt-getで取得できるようだ。（なんだ、ビルドしなくていいのか。）
# apt-get install dfu-util
  • そして、
$ dfu-util -l
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found Runtime: [0x0471:0xdf55] devnum=0, cfg=0, intf=0, alt=0,
  • これはＯＫ。PIDのdf55はdf 'U' のつもりだろう（大文字の'U'は0x55)


$ sudo dfu-util -R -t 2048 -D init-u-boot.rom
  • これがうまく行かない。
Starting download: [##################################################]
  • この後、firmware conflictが起こって先へ進まない。
  • init-u-boot.romの作り方を間違えたか・・・。
  • もしかしたらinit-u-boot.romがLPC313xのEvaluation Boardでないと起動しないようになっているのかもしれないが、詳細不明だ。
u-boot:     file format elf32-littlearm
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 0 .text         000119a0  33600000  33600000  00008000  2**5
                 CONTENTS, ALLOC, LOAD, READONLY, CODE
 1 .data         00001c21  336119a0  336119a0  000199a0  2**2
                 CONTENTS, ALLOC, LOAD, DATA
 2 .remtext      000194d8  33613600  33613600  0001b600  2**2
                 CONTENTS, ALLOC, LOAD, READONLY, CODE
 3 .rodata       0000118b  3362cad8  3362cad8  00034ad8  2**2
                 CONTENTS, ALLOC, LOAD, READONLY, DATA
 4 .rodata.str1.1 00005809  3362dc63  3362dc63  00035c63  2**0
                 CONTENTS, ALLOC, LOAD, READONLY, DATA
 5 .u_boot_cmd   000005cc  3363346c  3363346c  0003b46c  2**2
                 CONTENTS, ALLOC, LOAD, DATA
 6 .bss          0004b820  33633a40  33633a40  0003ba38  2**5
  • まさに、0x3000_0000〜にSDRAMを実装しないと動かない作り。
  • config.h -> ea31xx.h 
    #define CONFIG_SYS_MEMTEST_START    0x30000000  /* memtest works on */
#define CONFIG_SYS_MEMTEST_END      0x33FFFFFF  /* 64MB of DRAM */
  • 内蔵ISRAMは0x1102_8000〜0x1105_8000に実装されている。


  • あうあう、LPC3152はsecure bootではないけれど、LPC3154はsecure bootがサポートされていて、 secure keyを記憶するNAND Flash 2kBが余分に実装されている。
  • で、LPC3154はserialとDFUのみ、unsecure bootもサポートされている（らしい）

カタいな.

↑

Netduinoはファームウェアソースが公開されている。†

netduinofirmware.zip

CLR/Core/TypeSystem.cpp 
CLR/Core/Execution.cpp
CLR/StartupLib/CLRStartup.cpp
  • ヘッダーとか抜けている。たぶんVisutalStudio2010に丸依存しているのだろう。
  • てっきりMonoの成果が使われているのかと思ったら、全然そうじゃなかった。
  • (firmware)コード量がどのくらいなのかは分からなかった。
  • CLRに乗っかっている言語なら使えるらしいのでアプリを書くときにMonoを使うとか、VisualBasicを使うとかありなのかも。（もちろんWindowsのＧＵＩ依存のコードがARM上で動くわけではないが・・・）




↑

LPC2388: armon/armbootのメンテナンスを実施†

  • LPC1343で得られた経験を、STM32とNXPにバックポートしてみた。
  • ほぼどれのＣＰＵでも同じようなHIDブートローダーが使えるようになった。
↑

armon/armboot 移植済みの基板リスト†

LPC2388用はSTM32からバックポート

アーキテクチャーＣＰＵ(ベンダー)基板名FLASH容量SRAM容量
Cortex-M3STM32(STMicro)STM8S-DiscoveryのSTM32側64kB20kB
CQ-STARM　DesignWave 2008-05付録128kB20kB
STBEE　ストロベリーリナックス512kB64kB
STBEE　Mini128kB20kB
LPC1343(NXP)LPCXpresso　NXPセミコンダクターズ32kB8kB
TRZ1010N　トラ技増刊「ARMマイコン パーフェクト学習基板」32kB8kB
ARM7TDMILPC2388(NXP)CQ-FRK-NXP-ARM512kB64kB
  • 操作性やソースツリーはPIC18Fシリーズ用のpic18spxと大体同じになっている。
  • LPC2388のFlashへの書き込みも成功した。
  • ただし、LPC2388のアプリケーションブートがいまひとつ上手くいっていない。
    • LPC2388だけ、例外ベクターを自由にずらす(STM32のNVICコントローラーのような)ものを積んでいないのだ。
    • しかし、例外ベクターは０番地のハンドラー任せのままでも、LPC2388のVICレジスターに任意の割り込みアドレスを （要因ごとに）設定できるっぽいので（FIQはだめかも）、なんとか工夫すればいけそうな予感はある。

read more : ARM7mon


armon/armbootの移植対象の数がだいぶ増えたので、ソースを日付入りtarballを持つのをやめてsvnに移行してみた。

  • svnは楽かも。リリース(svn export後)のzip作成も自動化してみたり。
  • まちがってファイルごみ(*.bakみたいな)をパッケージする事故はだいぶ防げるみたい。



↑

LPC2388: Linuxは難しい・・・†

  • armon/armbootのLinux対応が出来ないかと、挑戦中。
  • HIDデバイスのインタラプト転送が出来ない。何故？
  • 引っかかってる箇所は、 
    int usb_set_configuration(usb_dev_handle *dev, int configuration);
int usb_claim_interface(usb_dev_handle *dev, int interface);
  • これをやらないと、エンドポイントのアクセスができない、というやつなんだけど
  • やるとエラーする。
  • エラーしたときに、 
    int usb_detach_kernel_driver_np(usb_dev_handle *dev, int interface);
  • すればいいというおまじないがあるらしいが、やってみてもその後のインタラプト転送はエラーする(-22)
  • なんでだろう・・・。

原因は、単純なコーディングミスだった。(detachしたあとで間違ったset_configurationする処理が残っていた・・・)


/ATMEL_AVR/jpg/ARM/armon-nxp.png

とりあえず、Linux(ubuntu10.04)で動いているスクリーンショット。

read more : ARM7mon　armon （STM32でもLinux版が少し動くようになった）





↑

armon/armboot: ついに、やっちまった・・・†

  • CQ-STARM基板を使って、armon/armbootのLinux版をテスト中の出来事だ。 
    $ sudo ./armboot -E
  • えらい遅い。ハングか？
  • Sleep()関数をsleep()につないだのが間違いだった。
    • 20m秒待つ-->20秒待つにされていた。
  • 正解は、usleep( n * 1000 ) らしい。


もいっかい。

$ sudo ./armboot -E
  • お、ちゃんと進んでる。
  • あ、１２８ｋＢをオーバーランしてもうた。
  • そうか、５１２ｋに拡張したんだっけ。
  • 電源を入れなおす。起動しない。DFUはとうの昔に消えている。というかDFUだろうが何だろうがFLASHの先頭に書かれたページが消えている。
  • 終了。文鎮の出来上がりだ。
  • 取り急ぎ、JTAGアダプターをCQ-STARMの40pin配列（の一部JTAG端子部分)に変換するピンヘッダー基板を作る。
  • （ピンヘッダーを少し曲げて、そのままCQ-STARMの40pinの一部に差込み、導通させているだけという・・・）
  • JTAGでmain-0000.hexを書く。

復活した。

  • その後、やはりバグっていて、また消してしもうた。
  • 現在公開中のarmon/armbootはこのバグを修正済みです。(Linuxでも動作する)
  • armboot -E をしなければ（あるいは128kを越えるhexを書き込みしようとしなければ）元から無問題。
  • （書き込みのほうは、自己ファーム領域を書き込まないようにガードしたんだけどなぁ）




↑

uboot: やはり、動かない。†

  • uboot/board/ea31xx/config.mk: 
    TEXT_BASE = 0x33600000
    これを 
    TEXT_BASE = 0x11040000
    に変えてビルドしてみた。
  • 実行。
  • 動かない。 
    Found Runtime: [0x0471:0xdf55] devnum=3, cfg=0, intf=0, alt=0, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=1628
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(10) = Device's firmware is corrupt. It cannot return to run-time (non- DFU) operations
Done!
can't detach: error sending control message: Broken pipe
Resetting USB to switch back to runtime mode
  • mapファイルを良く見たら、96kBはおろか、192kBに入ってない。 
    Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 0 .text         000119a0  33600000  33600000  00008000  2**5
                 CONTENTS, ALLOC, LOAD, READONLY, CODE
 1 .data         00001c21  336119a0  336119a0  000199a0  2**2
                 CONTENTS, ALLOC, LOAD, DATA
 2 .remtext      000194d8  33613600  33613600  0001b600  2**2
                 CONTENTS, ALLOC, LOAD, READONLY, CODE
 3 .rodata       0000118b  3362cad8  3362cad8  00034ad8  2**2
                 CONTENTS, ALLOC, LOAD, READONLY, DATA
 6 .bss          0004b820  33633a40  33633a40  0003ba38  2**5
  • bssが256kBを越えていた。
    • libfatが192kB確保しているらしい。


  • その後、いろいろ弄って.textのサイズを32kB程度に縮めてみたのだけれど、.bssと.remtestがなかなか縮まない。
  • そればかりか、.remtextセクションはなぜか .textのコードがいっぱい詰まっていて、サイズも96kB以上。
  • ところがmkbootimage.cが.remtextセクションを勝手に全削除してしまって、init-u-boot.romのサイズは32k未満になる。

全く不可解だ。

  • そもそも.remtextって、何なんだ。
  • u-bootはソース規模が大きすぎる。LPC3154のＬチカって、どっかに落ちてないかな・・・。

LPC3154は、ちょっと難易度高すぎたかな。


（NXPのサイトにある、）lpc313x.cdl.drivers.zipが、それらしい。

readme.txt

$Id:: lpc313x_readme.txt 1633 2009-02-06 02:21:00Z pdurgesh            $

NXP LPC313x Chip Support Package version 0.03

************************************************************************
************************************************************************
* Supported chip peripherals of the CSP
************************************************************************
************************************************************************
This CSP contains driver support for the following chip peripherals:
* LPC313x USB device (Memory back Mass storage example)
* LPC313x 10 bit ADC
* LPC313x Color LCD controller
* LPC313x Clock Generation Unit (CGU)
* LPC313x CRC32 driver
* LPC313x DMA controller (channel allocation driver only)
* LPC313x Event Router
* LPC313x I2C driver
* LPC313x I2S audio
* LPC313x Interrupt controller
* LPC313x IPINT/PCM driver
* LPC313x SD/MMC card controller/Memory card interface driver (MCI)
* LPC313x PWM
* LPC313x SPI
* LPC313x Timer 0/1/2/3 driver
* LPC313x UART driver
* LPC313x Watchdog timer driver (WDT)
* LPC313x GPIO controller (inline functions)
* LPC313x SysCReg (register access header driver)
  • CodeSourceryもサポートされていた。
  • LPC313xとLPC3154は主に容量の違いなので使えそうだ。
  • BSPというのは開発ボード毎のサポートパッケージで、CSPというのはチップ毎のサポートパッケージらしい。
  • CDLはコモンドライバーライブラリだそうだ。
↑

とりあえずLPC3154用Ｌチカをでっちあげてみる。†

  • スタートアップがKeilだかEARのアセンブラだったので全然通らない。
  • とりあえずLPC2388のcrt.Sをコピペしてみたけれど、全然だめかも。
  • 動くかどうかはまだ分からない。---ビクとも動かない。

dfu-utilが、formware corruptというエラーを吐いて止まる。

  • 原因はまったくもって分からない。
  • LPC3154はdfuでのnon-secureブートをサポートしているはずなのだが、
  • もしかしたら内蔵のfuseのようなものでsecure-boot限定になっているのかもしれないし、
  • 単純にバイナリーの作り方が間違っているだけなのかもしれない。

他にも、nand-bootとかsd/mmc-bootとかserial-bootとかJTAGとかいろいろ試し方は あるけれど、BGAパッケージなので未接続ピンに何かを繋ぐことはほぼ不可能だ。

  • もう諦めようかな。
↑

ほぼ諦めているけれど、ノウハウだけ書いておく。†

  • test-lpc3154.zipに全部入っているけれど
  • init-boot.bin （＝＝ 出来たelfをbin化して512の倍数サイズにしただけ） 
    000000: 23 00 00 ea 69 6d 67 41  00 00 00 00 00 00 00 00  #...imgA........
000010: 00 00 00 00 00 00 00 00  00 00 00 00 0a 00 00 00  ................
000020: 00 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  .@..............
000030: 00 80 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
000040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
000050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
000060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
000070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
000080: 00 00 00 00 00 90 02 11  00 90 02 11 00 d0 02 11  ................
000090: 00 10 03 11 d3 00 a0 e3  00 f0 2f e1 10 1f 11 ee  ........../.....
0000a0: f0 20 9f e5 02 10 01 e0  10 1f 01 ee 00 10 a0 e3  . ..............
  • 先頭の構造はlpc3154ユーザーマニュアルに書いてある通り。
  • offset 0x1cにある 000aというのが、CRC32チェックを省くオプション。
  • とりあえず、サイズは16kB(0x4000)、bssを含めて0x8000ということにしている。


  • init-boot.rom（＝＝init-boot.binをunsimgcrというツールで変換したもの） 
    000000: 10 00 00 e6 00 00 00 00  00 00 00 00 8e e5 ea 84  ................
000010: a8 ef 56 b9 52 71 05 db  00 40 00 00 00 00 00 00  ..V.Rq...@......
000020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
...
000800: 0c 28 0c e8 98 60 1c 47  59 60 58 b0 3a af 4e cd  .(...`.GY`X.:.N.
000810: 1d 2d 3b db 19 3b 19 0b  87 27 bf 30 45 a0 b7 33  .-;..;...'.0E..3
  • 先頭は0xe6000010固定。
  • その次は開始セクター（というかISRAM上のロード番地）で0のときが0x1102_9000番地で、1増えるたびに512だか4096だか後ろにずれていく。
    • ちなみにISRAMは0x1102_8000〜0x1105800までの192kBが実装されている。
    • 実行開始（というかロード）番地は0x1102_9000でいいとおもうけど・・・たぶん。
  • 0x800以降と、先頭のほうも暗号化されている。
  • unsimgcrコマンドはNXP提供品(i386-linuxのelf)
  • dfuで転送するときにセクターサイズ指定を2048にする。先頭2048(0x800)がヘッダーで その後ろは暗号化されたファームという感じ。
  • dfuのデバイス側ブートシーケンスもlpc3154ユーザーマニュアルに書いてある通り。

でもブートしてくれない。




↑

lpc-armon:Linuxに対応。†

  • LPC1343用の armon/armboot をLinuxでも使えるように改良した。
  • これで、全機種（というか全基板）Linuxから弄れるようになった。

read more : lpc-armon

  • MacOSにも対応したいけど、自由に使えるMacOSが手元にないんだな。
  • あ、MacOSではcode sourcery G++がないかも。クロスコンパイラも用意しないとだめなのかな。
  • 自分はいつもWindowsだけでやってる。たまに（というかLinuxでないとビルドできないようなものを触るときだけ）VMWare内のubuntuを起動するか、素のLinux(常時起動しているサーバー)にログインする感じ。
  • 常時起動しているサーバーは、玄箱なので遅い。:-)




↑

ＬＰＣＸｐｒｅｓｓｏ　ＮＸＰ　ＬＰＣ１７６８評価キット†

秋月電子

■動作クロック周波数：７２ＭＨｚ（搭載マイコンの最大動作周波数は、１００ＭＨｚ）
■プログラムメモリ：５１２ＫＢ
■ＳＲＡＭ：６４ＫＢ
■コアはＡＲＭ社のＣｏｒｔｅｘ−Ｍ３を採用

http://akizukidenshi.com/img/goods/C/M-04117.JPG

寸評:

  • 基板を切り離すのが毎回面倒だ。
  • ターゲット側がUSB OTGなのはいいけれど、コネクタ実装されてない。
  • ちゃんと100MHzにクロックアップ出来るんだ。
  • またLPC3154基板が余るな。どうしよう。
  • LPC1343より１００円高い。
  • JTAGで書けるんだ。（LPC-LinkはJTAGをサポートしてるんだろうか？）
  • SRAMは32k+32k構成で、片方の32kはUSB,Etherなどのバッファと共用だ。(LPC2388は64kの他に16k+16kある)

LPC2388(CQ付録)の石は適度に熱くなる（パワーが大きい）んで、乗り換えようかな。




↑

ＬＰＣＸｐｒｅｓｓｏ　というかCode Red 縛り†

やはり、ＬＰＣＸｐｒｅｓｓｏでダウンロード出来るファームのサイズは１２８ｋＢまでらしい。

だけど、こいつ（LPCXpressoのIDE）って、Eclipse+gccだったような気が思いっきりするんだが・・・。

  • つまり、LPCXpressoというのはCodeRedの反則販促品だったのか・・・。
  • たいていの人はＬチカくらいしかしないので、128kでも全然オッケー（違うぞ）
  • なこたあない。
    • LPC1343でなくて1768な理由はEther繋いでtcp/ipスタックくらい試す勢いの人が使うので、128kでは全然足りないという結論に達す。


思うんだけれど、LPCXpressoのLPC-Link側って、明らかにオーバースペックだよなぁ・・・。

  • ターゲット側がLPC1768までなら、USBがHighSpeedである必要ないしARMコアだって72MHzで充分だろ。
  • まあ、贅沢な石を使ってくれているんで文句は言えないんだけど。




↑

メモ：ARM Debian/Ubuntuの上でAndroidを動かす†

KMC Staff Blog:

既存のソフトウェアをAndroidで再利用する


2chスレだと、このへん

Googleって、ほんとはAndroidを無料（に近い）端末として配布したかったらしいんだけど、キャリアの壁があって挫折したとかいう話を聞いた。

で、結局、中華だけが(iP*dのパチモン用ＯＳとして）盛り上がってるような感じか。

もしAndroidが無かったらほんとにAppleの独壇場になったんだろうなぁ・・と。



↑

LPC2388: armon/armbootのメンテナンス完了†

  • HIDブートローダーとしてちゃんと動くようになった。
  • user関数からprintfを試すことが出来るようになった。
  • 32kBを超えるhexを正しく書き込めるようになった。
    • LPC2388のFLASHは32kB以前と0x78000以降が4kB/SECTORで、32kB以降0x78000番地までが32kB/SECTORになっている
    • ERASEやWRITEするときのページ番号は、SECTORの先頭からの数を数えて与えないといけない（番地ではない）
  • Linuxからも使える。
    read more : ARM7mon　armon



↑

STM32 Value line Discovery†

STM8S-Discoveryの 燃えないゴミ 側がパワーアップしとる。

PDFマニュアル


寸評

  • 基板がもはや切り離せない。
  • 燃えないゴミが32bitにパワーアップ
    • STM32F100RBT6B 128 KB Flash, 8 KB RAM 64-pin LQFP
    • Cortex-M3だが、24MHz動作
    • ターゲット側にはUSB I/Fが存在しない。
    • 12bit ADCと12bit DAC x 2 （ステレオ？？）がある。
    • HDMI(???)
    • 水晶が３個も載っている(8MHz x 2 , 32768 x 1)
    • JTAGはない。SWD専用。

で、値段はいくらなんだろう。まあ、アレが750円だったから980円くらい？？？(1050円かも・・・)

  • ST-Link側と燃えないゴミ側の接続が２線式(SWD)だけっていうのはいただけない。
  • Arduinoでさえ、RxD/TxDが繋がってfirmata出来るのに。

もちろん２線式でST-Link側がUSB to soft I2C converterになれるのなら、それっぽいfirmataになるけれど、 そんなファームが供給されるとは到底思えないんだ。

７５０円の片割れのほうがよっぽど使い道があるような気がした。


この基板についての詳細はここに詳しく載ってました。



酷い言い方で、とてもblogになんか書けないんだけど、

  • この基板は燃えないゴミCPUを剥いでしまってST-Link側CPUの手足をピンヘッダーに出して使うしかないと思っている。もし買うとしたらだけど。
  • 多分買わない。だってほら、もうARM基板なんてCQ出版の付録を大人買いしたストックが溜まってお腹一杯なんだ。
  • そろそろPIC18Fに戻ろう。


↑

そういえばOpenOCDをビルドすることをすっかり忘れてた。†

  • そろそろやるか。涼しくなったことだし。





↑

デルから10型タブレット / ノート Inspiron Duo、デュアルコアAtom採用†

Engadget

  • http://japanese.engadget.com/2010/09/14/10-inspiron-duo-atom/
  • 今年始めのDELL Mini10v２万円投売りセールに乗り遅れた俺としては、こんどは乗り遅れないようにしよう。
  • 英語キーが選べるのはDELLしかないし。
  • これと同程度メモリーが載っててCPUがARMならなお可なんだけど。

ていうかこれ４万超えるのかなぁ・・・。ううむ。

  • 中華Androidはどれもキーボードついてないし、まともにメモリー載ってないし、何よりubuntuが使えないんじゃあ・・・





↑

LPC3154 questions...†

Yahoo Group

英語良く分からないんだけれど、

  • BlankのLPC3154を持っていて、それと置き換えればit will not take any custom firmwareじゃなくなるのか？？？
  • そもそもブランクのLPC3154と、書き込み済みのLPC3154というところが良く分からないんだけど。
  • Flash載ってないだろ。
  • まさか内蔵Fuseとか小容量Flashのようなものを持っている？？？


なんか鍵掛かってる？そうなのか？良く分からん。





↑

NXP’s 150 MHz LPC1800 MCU Delivers Industry’s Highest ARM Cortex-M3 Performance†





↑

「ノートPCや3D TVをiPadが喰う」：米国販売店†

  • http://wiredvision.jp/news/201009/2010092120.html
  • WindowsPCからiPad化は予想以上の速度で進んでいて、
  • Microsoft社の存続が危うい --- じゃあなくて、iPadの有力な対抗馬は（今になっても）存在しない。
  • Android搭載MIDデバイス--->中華製--->品質悪すぎ（日本人がそう思うだけかもしれないが）--->逆にiPadの引き立て役にさえなっている。
  • Windows7搭載ATOMデバイス--->遅くて使いにくい皆んな、Windows7は必要ないと考えている。
  • ubuntu搭載SmartBook--->Geekな人しか買わない。--->市場が無い。

結論は、Appleの一人勝ち状態が継続しているということ。


このままいくとMicrosoft社の存続がマジやばいかもね。---MIDデバイスにWindowsCE要らない-->Android化している。MicrosoftのOS(Windows7しかないんだけど)が避けられている。ということは、もうひとつの収入の柱であるMicrosoft Officeの実行環境もどんどんパイが狭くなっていくわけで・・・。どうする？



↑

LPC2388/LPC1343/STM32F10x : armon/armbootのメンテナンス完了†

  • 全機種で 'p'コマンドが使えるようになった。(portアドレスをいちいち覚えなくて良い)
  • Linuxからも使える。
  • host側ソースを共通化。


read more : LPC2388用　LPC1343用　STM32用　




↑

ニンテンドー3DSはデュアルARM11 at 266MHz、1.5GBストレージ内蔵？†

  • でも、この文面どおりだったとしたら、SONY PSPと瓜二つ。(ARMでなくMIPSという違いはあるが)
  • 3DSはTegra搭載しなかったけれど、もう片方のやつはTegraの噂が立っているらしい。
  • Tegraって呪われてるからなぁ・・・（某Microsoft携帯の潰れたほう）



↑

これはひどい：検事が押収フロッピー書き換え、8インチに─不正郵便事件†

BogusNews

8inchの写真を検索

  • しかし、1.44MBの3.5inchを8inchに移したら、何枚に増えるのかな？２枚？



↑

STM32マイクロコントローラのシンクライアント†

Make: Japanより

http://github.com/davidcranor/Thinner-Client/blob/master/Pictures/photo%201.JPG
NTSCのビデオ信号をすべてハードウェア内で行い、完全な480x240のフレームバッファを持つ。
コードはすべてCで書かれている。加えて、簡単、自由にビットマップグラフィックを
フレームバッファに描けるように、また、シリアル受信バッファ、キーボードキャラクタバッファに
アクセスできるよう記述されている。
  • シンクライアントと聞いて、全然ピンと来るものが無かった。
  • だって、Thin-Clientって、Ｘ端末のことだろ？違う？
  • これは、どうやら、（TTLレベル）RS-232シリアル仕様のvt-100っぽい tty端末のことだ。
今回のプロジェクトで使用したSTM32は80MHzで動作する。
数多くの周辺機器があり、DMA、豊富なRAM/Flash、内蔵シリアルブートローダーを備え、価格は6ドル前後。
私はもう二度とAtmegaは使わないだろう。
  • 上の２行には同意だが、最後の行には同意しかねる。
  • AVRでやるから価値があるものだってあるのだ。
  • (AVRよりずっと性能が高いマイコンでは、出来るのが当たり前。、それはちっとも面白くない)



↑

サムスンのAndroidタブレット Galaxy Tab†

Engadget

この軽さが凄いよな。

  • って煙草のＣＭかよ。
  • iPadみたいに、WiFi版が出るなら買ってもよいけど。
    • 3Gでどこでも接続 (WiFi のみ版もあり)、マジかよ。困ったな。



↑

Arduino UNO†

GIZMODE

  • http://www.gizmodo.jp/2010/09/arduinoduemilanoveunomega.html
  • FT232RLの代わりにATmega8U2がUSBチップの役割を果たしている。
  • これって、ATmega328なくてもいいんじゃないか？8U2の手足をそのまま出せば。
  • 互換性持たせるにはこれしかないんだろうけど、なんだかなー。
  • ARMなら１チップで済むのに。
  • 最近の傾向として、ArduinoチックなものにさえＬＷＰ（軽量プログラミング言語）が進出しているとか、Etherを持ったものが現れているので、
  • もうAVRでは荷が重く、きっぱりARMに移行すべき時期なんだけど。



↑

“Javaの父”ゴスリング氏、Oracle退社の理由を語る (2/2)†

http://www.itmedia.co.jp/enterprise/articles/1009/27/news020_2.html

Oracleには非常に傲慢なところがある。
  • ここまで読んだ。
  • 最初から分かっていた？



↑

マウス、Androidタブレット「LuvPad AD100」を発売延期†

  • 中華の嫌がらせに引っかかったか、あるいは
  • Tegraって、やっぱ鈍われ呪われてる


  • しかし、中華の嫌がらせはどこまでエスカレートするつもりなんだろ？
  • まるで北朝鮮と同じ、というか、同じ共産党なんだよなー。無理ないか。



↑

STM32F10x : armon/armboot用のサンプルアプリケーションを追加†

  • とりあえず、vcom（仮想COM）サンプルのビルドが通るようにしてみた。


read more : STM32用armon/armboot　／　LPC1343用armon/armboot（作成途上）　



↑

OpenOCDのWindowsビルドに挑戦。†

実は超簡単だったのだ。

  • 一応cygwinからexeファイルを作るのには成功していたけれど、cygwin1.dll依存になるのでMinGWベースのOpenOCDが欲しかった。
  • cygwin上にはautoconfをはじめとするconfigureに必要なツールがほぼ揃っているけれど、Windows上のMinGWでそれをやるのは難しい。
↑

今回は、Linux(ubuntu 10.04LTS)上でやる。†

  • ものの１０分もあればexeが出来上がる。

まず、必要そうなパッケージをapt-getで取得

# apt-get install git-core
# apt-get install gcc-mingw32
# apt-get install mingw32
# apt-get install libconfig8
# apt-get install libtool
# apt-get install autoconf
# apt-get install automake
# apt-get install cmake
# apt-get install texinfo
  • libftd2xx(CDM20602.zip)をFTDIサイトから取得して展開
$ mkdir libftd2xx-win32
$ cd libftd2xx-win32
$ unzip ../CDM20602.zip
$ cd ..

ファイル名はバージョンが変わると変わるかも。

  • もしFTDI配布物がzipでなくexeだったら、Windows上で展開して持ってくるか、 wine(Windowsエミュレータ)を使って実行する。


  • OpenOCDソースの取得
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
  • ビルド
$ cd openocd
$ ./bootstrap
$ ./configure \
       --build=i686-pc-linux-gnu \
       --host=i586-mingw32msvc \
       --enable-maintainer-mode \
       --enable-ft2232_ftd2xx \
       --with-ftd2xx-win32-zipdir=../libftd2xx-win32
$ make

これでsrc/openocd.exe が出来上がる。

  • Linuxなのに(exeファイルが完成する)不思議。
  • MinGWのクロスコンパイラをわざわざビルドする必要もなかった。(apt-getで取得)
  • 動作確認はまだ。

結論：

  • とにかくubuntuは良い。
  • 速いし、ソフトウェアパッケージはDebianと同じくらい充実しているし。
  • apt-getで最新ソフトが何でも手に入る。野良ビルドの必要がほとんどない。

野望など：

  • OpenOCDのUSB-Blaster対応はひどくのろいので、もうすこし手軽で使い物になるJTAGアダプターを作りたい。


  • もちろんFTDIのチップを使えば出来る（すでに持っている）のだけれど、難点が・・・
    • 秋月FT-2232モジュールで製作する場合、シリアルEEPROMの入手と、電圧レベルコンバータの入手がネックになる。
    • 電圧コンバータを実装しない場合でも3STATEのCMOSゲートを２組ほど実装しないといけないので面倒。（手持ちだと74HC244っぽいやつ(644とか645)を２個使わないと出来ない）
    • 適当なUSBマイコン(PIC18FとかAVRとかARMとか)でやればほぼ直結でいけるのに(お互い3.3V品に限定の話)
  • OpenOCDはソフトウェアの規模がかなりでかいので、ドライバー部分しかいじれないというか、手に負えないかも。