ARM Cortex-Aシリーズまとめ(3) 64bit編

これまでのあらすじ
32bitと違って64bitの方は前回2012年10月発表のCortex-A57とCortex-A53しかないのでそこから発表されたものをまとめたいと思います。

Cortex-A72(2015/02/03発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a72-processor.php

• 命令セットはARMv8-A
• 持続性能はCortex-A15比で3.5倍、Cortex-A57比で1.84倍(但しプロセスルールの微細化を含む)
• 消費電力はCortex-A15比で75%減(但しプロセスルールの微細化を含む)
• AArch32/AArch64
• ハードウェア仮想化/TrustZone/NEON(SIMD)/VFPv4(FPU)
• 6.3〜7.35DMIPS
• 0.5~4MB L2キャッシュ
• 3イシューのスーパースカラー
• 15段パイプライン/アウトオブオーダー実行

Cortex-A72の採用プロダクト

• MediaTek Helio X20(Cortex-A72/Cortex-A53)
• Qualcomm Snapdragon 650(旧称Snapdragon 618) MSM8956(Cortex-A72/Cortex-A53)*1
• Qualcomm Snapdragon 652(旧称Snapdragon 620) MSM8976(Cortex-A72/Cortex-A53)*1
• HiSilicon Kirin 950(Cortex-A72/Cortex-A53)

Cortex-A35(2015/11/10発表)

http://www.arm.com/ja/products/processors/cortex-a/cortex-a35-processor.php

• 命令セットはARMv8-A
• Cortex-A7比で消費電力10%減、Cortex-A53比で消費電力32%減
• コンフィギュレーションを絞ることで一層のダイサイズ/消費電力の縮小が可能
• AArch32/AArch64
• ハードウェア仮想化/TrustZone/NEON(SIMD)/VFPv4(FPU)
• 2イシュー
• 8段インオーダーパイプライン
• リテンションにより、段階的に未使用回路の消費電力減が可能
• Cortex-A72、Cortex-A57とbig.LITTLE構成を取れる

Cortex-A35の採用プロダクト
TBD

*1 Snapdragon 618/Snapdragon 620はそれぞれSnapdragon 650/Snapdragon 652に変更されました(2015/12/17発表) https://www.qualcomm.com/news/snapdragon/2015/12/16/snapdragon-600-tier-processors-repositioned-reflect-advanced-performance

ARM Cortex-Aシリーズまとめ(2) 32bit編

これまでのあらすじ

かなり一念発起して書いた前回[1]のまとめですが、当時最新でも今となってはなかなか懐かしさあり、でもまだ市井のスマホ・タブレットは大部分カバーできています(Qualcommの自社デザインのもの以外は)。まぁでも2013年の1月に書いたものなので使い出はまだあるかなぁと思っていますが、今回の自分用まとめを書くにあたって前提を以下とします。

• 32bitと64bitは分ける(ARMがbig.LITTLE構成で32bitと64bit混在させてないので。64bitは別エントリにする)
• 出発点はCortex-A15/Cortex-A9/Cortex-A7/Cortex-A5のみとする
• Cortex-A15→ハイエンド(32bitにおいて。以下同様)
• Cortex-A9→パフォーマンス(ミッドハイ)
• Cortex-A7→省電力(ミドルレンジ)
• Cortex-A5→省電力かつダイ面積最小(ローエンド)

以上の前提のもと、今回記載するグラフは以下の通りとなりました。

Cortex-A12(2013/06/03発表)
(ARM社のURLなし→Cortex-A17に統合されたため？)

• 1TBアドレススペースをアドレス可能 LPAE(Large Physical Address Extention)
• ハードウェア仮想化・TrustZone
• 同クロックCortex-A9比で40%高速
• 2イシューのスーパースカラー
• 11段パイプライン/アウトオブオーダー実行
• VFPv4 FPU/NEON SIMDがオプションから統合へ変更
• Cortex-A7とbig.LITTLE構成を取れる
• Cortex-A9時代では想定していなかった細かいプロセスルールでの製造
• 3.00DMIPS
• Thumb-2
• L2キャッシュ(0-8MB)は同一クラスタのCPU間で共有

割と短期間で発表されたCortex-A17が吸収したようです。

Cortex-A12の採用プロダクト
TBD

Cortex-A17(2014/02/11発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a17-processor.php

• 同クロックCortex-A9比で60%高速(NEON/VFPv4は50%高速)
• Cortex-A7とbig.LITTLE構成
• LPAE(Large Physical Address Extention)・TrustZone・LPAE
• NEON,VFPv4
• 10-12ステージパイプライン/アウトオブオーダー実行
• 4.00DMIPS
• Thumb-2
• L2キャッシュ(256KB-8MB)

Cortex-A17の採用プロダクト
MediaTek MT6595 (Cortex-A17/Cortex-A7)

まとめ
Cortex-Aシリーズの32bitのラインは大きく3つに収斂されました。

• Cortex-A9をベースにリファインをしたCortex-A17が性能でおよそCortex-A15と並んだため、今後32bitのハイエンドはCortex-A17
• Cortex-A7がミドルレンジ
• Cortex-A5がローエンド

[1] http://utimukat55.blogspot.jp/2013/01/arm-cortexa57a53.html

URIと判別すべき文字列

手元でちょこちょこ作ってるServletで、入力として渡される文字列に対してリンクを生成してるのだけど、リンクを生成しても意味がない(URIではない)文字列かどうかを判別する処理を考える。
とは言っても、リンクとして生成すれば何でも相対パスとしては正しいリンクなので、それはそれとして捨てる感じで(URIエスケープされているかどうかという観点でやるのが一番良いのだろうけど)

定義を確認

というわけで、URIのRFCを参照して、URIスキームのABNFを確認。[1][2]

• URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
• scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
• ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
• DIGIT          =  %x30-39   ; 0-9

端的には、アルファベットから始まるアルファベットと数字と+と-と.から始まって:で終わる文字列で始まる文字列ということで。

[1] http://tools.ietf.org/html/std66#appendix-A
[2] http://tools.ietf.org/html/std68#appendix-B

特定のMACアドレスに対してIPv6アドレスを設定するDHCPv6サーバを構築した(4)-DHCPv6サーバの設定再び

前回までのあらすじ

• DHCPv6サーバはISCのものにパッチを当てたものをパッケージとして作ってインストール
• DHCPv6クライアントはISCのものを使って、クライアントを手動実行
• クライアントから送るDHCPv6 soliciteが期待通りにならない(DUIDが)

サーバ側の設定を変更

/etc/dhcp/dhclient.confに記載したDUIDは例のwide_mkduid.plで生成したもので、Hardware typeが6(IEEE802)となっていたのだけど、ISCのdhclientは1(Ethernet)としてDUIDを作るので、こっちに寄せることにしてファイルの内容を変更[1]。最終的には以下。

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;
option dhcp6.info-refresh-time 21600;
dhcpv6-lease-file-name "/var/lib/dhcp/dhcpd6.leases";
# RAとか範囲とか(うちの場合はRTX1100で配っているRA)
subnet6 fd00:dead:beef::/64 {
 # 1000からffffまでをDHCPで配る対象にする
 range6 fd00:dead:beef::1000 fd00:dead:beef::ffff;
 # 固定IPアドレス
 host kurobox-t4 {
  host-identifier option dhcp6.client-id 00:03:00:01:00:16:01:xx:yy:zz;
  # 固定で振るIPv6アドレス
  fixed-address6 fd00:dead:beef::100;
 }
}

DHCPサーバを再起動。

# /etc/init.d/isc-dhcp-server restart

DHCPv6クライアント側はDUIDタイプはdhclientのmanを注意深く読んだ結果、引数「-D LL」を指定することでLLを強制的に指定できそうだったので、/var/lib/dhcp/dhclient6.leasesの中身を空にして[2]、起動方法を以下の引数へ変更して実行。

# dhclient -6 -D LL -cf /etc/dhcp/dhclient.conf eth0 -v

一応これで当初望んでいた「fd00:dead:beef::100」は設定されるようになったので「特定のMACアドレスに対して固定IPv6アドレスをDHCPv6で設定する」は達成できたと思いますが、いくつか条件付きなのはここまで記載したとおり。

• DHCPv6サーバがデフォルトだと扱いづらい
• dhclientの起動方法が手動
• DUIDがLLのみ(LL+Tだと対応できない)

サーバ側もクライアント側も結局一筋縄でいかないのは間違いないと思うので、できるだけ早いとここの辺が解決するといいなぁと思っています。

[1] 00:03:00:06から00:03:00:01へ

[2] 空にしないと、取得済みのアドレスを載せたDHCPv6 confirmを送り続けます

特定のMACアドレスに対してIPv6アドレスを設定するDHCPv6サーバを構築した(3)-DHCPv6クライアントの設定

DHCPv6クライアントの設定
クライアント側パッケージはisc-dhcp-clientを使います。サーバ側をisc-dhcp-serverにしたからというだけですが、一応バージョンはdebianの4.2.4-7[1]を使いました。これより前のバージョンでも動くかもしれません。
で、いろんなサイトを見ながら設定を探しつつ…とりあえず[2]の設定がよさげかなぁと思ってこれをベースに。
以下の2行を/etc/dhcp/dhclient.confに書き足して。

send dhcp6.oro 3,23,24,31;
send dhcp6.rapid-commit;

NIC再起動すりゃこの設定したdhclientがDHCPv6 solicite投げるだろjk…

# /etc/init.d/networking restart

……パケット取ってるwiresharkに一向にDHCPv6パケットが流れてこない……

DHCPv6クライアントを手動で実行する
まさかの手動実行ですよ。何か設定が間違ってるのかもしれませんが小職のスキルでは悪いところが見つけられませんでした。

で、とりあえずman dhclientしてみて、dhclient --helpしてみて、それっぽい引数を探します。

# dhclient --help
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Usage: dhclient [-4|-6] [-SNTP1dvrx] [-nw] [-p <port>] [-D LL|LLT]
                [-s server-addr] [-cf config-file] [-lf lease-file]
                [-pf pid-file] [--no-pid] [-e VAR=val]
                [-sf script-file] [interface]

ふむ。とりあえずDHCPv6クライアントとして実行する場合は-6と、最後のinterfaceは指定したほうがよさそう。ついでに一応設定ファイルを-cfで明示的に指定してみよう。あとは動きを確認するために-v(よくあるverbose)。

# dhclient -6 -cf /etc/dhcp/dhclient.conf eth0 -v

実行結果。

Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Bound to *:546
Listening on Socket/eth0
Sending on   Socket/eth0
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
'send dhcp6.oro' syntax is deprecated, please use the 'request' syntax ("man dhclient.conf").
XMT:  X-- IA_NA 01:96:49:2b
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1060ms.
RCV: Advertise message on eth0 from fe80::213:e8ff:fexx:yyzz.
RCV:  X-- IA_NA 01:96:49:2b
RCV:  | X-- starts 1391264700
RCV:  | X-- t1 - renew  +3600
RCV:  | X-- t2 - rebind +7200
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR fd00:dead:beef::c7e5
RCV:  | | | X-- Preferred lifetime 604800.
RCV:  | | | X-- Max lifetime 2592000.
RCV:  X-- Server ID: 00:01:00:01:1a:7f:8d:59:00:13:e8:xx:yy:zz
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:01:00:01:1a:7f:8d:59:00:13:e8:xx:yy:zz (s: 153, p: 0).
XMT: Forming Request, 0 ms elapsed.
'send dhcp6.oro' syntax is deprecated, please use the 'request' syntax ("man dhclient.conf").
XMT:  X-- IA_NA 01:xx:yy:zz
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR fd00:dead:beef::c7e5
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth0, interval 960ms.
RCV: Reply message on eth0 from fe80::213:e8ff:fexx:yyzz.
RCV:  X-- IA_NA 01:xx:yy:zz
RCV:  | X-- starts 1391264702
RCV:  | X-- t1 - renew  +3600
RCV:  | X-- t2 - rebind +7200
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR fd00:dead:beef::c7e5
RCV:  | | | X-- Preferred lifetime 604800.
RCV:  | | | X-- Max lifetime 2592000.
RCV:  X-- Server ID: 00:01:00:01:1a:7f:8d:59:00:13:e8:xx:yy:zz
PRC: Bound to lease 00:01:00:01:1a:7f:8d:59:00:13:e8:xx:yy:zz.

お。動いてる[3]。動いているが。DHCPv6サーバから振られているアドレスが「fd00:dead:beef::c7e5」である。前に書いたとおり動いていれば振られるアドレスは「fd00:dead:beef::100」になるはずなのであるが。一応ifconfigでも確認。

# ifconfig
eth0      Link encap:イーサネット  ハードウェアアドレス 00:16:01:xx:yy:zz
          inetアドレス:192.168.1.33 ブロードキャスト:192.168.1.255  マスク:255.255.255.0
          inet6アドレス: fd00:dead:beef:0:216:1ff:fexx:yyzz/64 範囲:グローバル
          inet6アドレス: fe80::216:1ff:fexx:yyzz/64 範囲:リンク
          inet6アドレス: fd00:dead:beef::c7e5/64 範囲:グローバル

うむやはり。c7e5はDHCPv6サーバからリースする範囲(1000からffff)の範囲には入っているので、DHCPv6サーバ自体は機能してそう。
サーバ側のログを見てみると。

Feb  1 23:25:36 lmdecfy7 dhcpd: Solicit message from fe80::216:1ff:fexx:yyzz port 546, transaction ID 0x792D6600
Feb  1 23:25:36 lmdecfy7 dhcpd: Picking pool address fd00:dead:beef::c7e5
Feb  1 23:25:36 lmdecfy7 dhcpd: Sending Advertise to fe80::216:1ff:fexx:yyzz port 546
Feb  1 23:25:37 lmdecfy7 dhcpd: Request message from fe80::216:1ff:fexx:yyzz port 546, transaction ID 0xA4A60600
Feb  1 23:25:37 lmdecfy7 dhcpd: Wrote 0 deleted host decls to leases file.
Feb  1 23:25:37 lmdecfy7 dhcpd: Wrote 0 new dynamic host decls to leases file.
Feb  1 23:25:37 lmdecfy7 dhcpd: Wrote 0 leases to leases file.
Feb  1 23:25:37 lmdecfy7 dhcpd: Sending Reply to fe80::216:1ff:fexx:yyzz port 546

ということで、どうも適当に在庫からアドレスを拾ってきていてそれがc7e5ということらしい。うーむ。色々がんばったつもりなんだが。

パケットを見てみると、どうやらDHCPv6 soliciteの中にクライアントから送られるDUIDが含まれているらしいということを知る。

DUID type: link-layer address plus time (1)
Hardware type: Ethernet (1)
Time: Feb  1, 2014 23:25:00 JST
Link-layer address: 00:16:01:xx:yy:zz

マジかよ。とりあえず2つおかしい。

1. DUIDタイプがLL+T(MACアドレスと時刻)になっている
2. Hardware typeがEthernetになっている

DUIDタイプは時刻がいつになるかわからない時点で知ったこっちゃないので、LLになるといいなぁと思っていたので、正直参る。

このエントリはここまで。

[1] http://packages.debian.org/ja/jessie/isc-dhcp-client
[2] https://wikispaces.psu.edu/display/ipv6/DHCPv6#DHCPv6-ISCdhclient4.1.0
[3] MACアドレス該当部はぼかしています

特定のMACアドレスに対してIPv6アドレスを設定するDHCPv6サーバを構築した(1)-序章

やる前は1エントリで済むと思ってたんですが実際やってみるとすげー大変だったのでいくつかに分けます。

現状＆やりたいこと

我が家では部分的にIPv6を導入していて、VPN(L2TP)ルータとしてヤマハのRTX1100を使っています。また、RAもRTX1100からLAN側に流していて、ステートレスなIPv6アドレス設定はできている状態です。

ですが、ご存知の通りIPv6アドレスは長い事、ステートレスに生成するIPv6アドレスは128bitぶんのアドレスを使い切る(0ではない)ので、LAN内のサーバにも頻繁にアクセスするには辛いアドレス(手入力したくない)が設定されます。[1]
そこで、IPv4では家庭用のブロードバンドルータでもできるような「特定のMACアドレスに特定のMACアドレスを配布する」をIPv6で実現しようと思いました。よく言うDHCPv6によるステートフルなIPv6アドレス割り振り(しかも固定アドレス)です[2]。

せっかくヤマハルータあるんだからコマンドいくつか流しこめば出来るんじゃないかと思ったんですが、現状のヤマハルータではRTX1100に限らずこの機能が提供されていません。

なので、LAN内のPCをDHCPv6サーバにしてみようというのが今回のスタート地点です。

今回の記事の全容は以下になります。

1. 序章←今ここ
2. DHCPv6サーバの設定(1)
3. DHCPv6クライアントの設定
4. DHCPv6サーバの設定(2)

RTX1100の設定はこんな感じです。

• LAN1がLAN
• 配布するRAのprefixはfd00:dead:beef::/64
• DHCPv6使うのでRAのMフラグは立てる

具体的には

• # ipv6 prefix 1 fd00:dead:beef::/64
• # ipv6 lan1 prefix fd00:dead:beef::/64
• # ipv6 lan1 rtadv send 1 m_flag=on

このエントリはここまで。

[1] AAAAレコードを返すDNSサーバを置いても解決できる問題ではありますが
[2] ステートフルの定義を理解できてないかもしれないので間違っていたら教えてください

DHCPv6について(DUID)

DHCPv6で(各ホスト上の手動設定ではなく)静的にアドレスを振る方法について調べていて、DUIDというものに辿り着いた。忘れないように書きだす。

DUIDとは
色々世の中にはIDを振る方法があるのだけど、DHCPの仕組みで使われる(と思われる)IDの振り方。DHCP Unique Identifierの略。

RFC3315で定義されているDUID
RFC3315(DHCP for IPv6)[1]のSection-9で定義されているDUIDは３つ。

• DUID-LLT(DUID Based on Link-layer Address Plus Time)
• DUID-EN(DUID Assigned by Vendor Based on Enterprise Number)
• DUID-LL(DUID Based on Link-layer Address)

DUID-LLTとDUID-LLに書かれている「Link-layer Address」は日本語でいう物理アドレス、いわゆるMACアドレスのことで、LLTの方はMACアドレスと時刻から導出、LLはMACアドレスから導出という事らしい。
一方でDUID-ENはIANAがメンテしているPrivate Enterprise Numberに各ベンダが持っているIDを振っていく形式のようだ。
これら3つのIDのオフセットはRFC3315を参照。

RFC6355で定義されているDUID
それでいて、RFC6355(DUID-UUID)[2]でもDUIDが定義されている。
DUID-UUIDはRFC4122で定義されているUUIDをそのまま使う(正確にはDUID-Typeである4の後ろにDUID128bitを繋げる144bit)ということ。UUIDはあんまり重複しないのでこれの方が手軽という事なんだろうか。

もうちょっとだけ続くんじゃ(2014/02/04追記)
元々あるDUID-LLTとDUID-LLについて、dhclientがデフォルトで投げるDUIDがDUID-LLTになっているので、何で似たようなものが２つあるのかdhclientのデフォルト設定について調べていたらバグとして報告されていた[3]。
その中でComment21に

> So it seems like we all agree that DUID-LL is the way to go...
AFAIK even the RFC agrees :).

と書いてあり、それならと思って改めてRFC3315を読んでみると、まずDUID-LLTがある理由は

• DHCPv6クライアントとDHCPv6サーバとの間で重複しないIDが必要
• NICを機器の間で付け替えたとしても、別々のIDになるようにする

ために、MACアドレスと時刻を複合キーのように扱ってIDとして使う。との事。

ではDUID-LLが定義されている理由は。

This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device.  For example, a host that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL.

要は、「NICを取り外し不可能なプロダクトに限ってDUID-LLを使ってもいいよー」的なノリで書かれているので、デフォルトはDUID-LLみたいな事になっているようだ(RFC3315を書いた時のノリでは)。

それと、DUID-LLTとDUID-LLの3〜4オクテット目に使われるhardware typeはIANAでメンテされていて[4]、どういう風に識別されているかはDUIDを生成するDHCPv6クライアント次第であることにも注意が必要である。(DHCPv6サーバ側でDUIDを元にした処理をする場合があるので。)
具体的には、6(IEEE 802 Networks)かと思ったら1(Ethernet (10Mb))だったりするので。

[1] http://tools.ietf.org/html/rfc3315#section-9
[2] http://tools.ietf.org/html/rfc6355
[3] https://bugzilla.redhat.com/show_bug.cgi?id=560361
[4] http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2

IPv6の特殊なアドレスについて

RFC6890をちゃんと見たら色々あったので。

IPv4互換アドレス/IPv4-Compatible IPv6 address(廃止済み)
かつてあったんですがIPv6自動トンネリングが廃止になったので一緒に亡くなりました。無意味に使うのやめましょう。

• ::/96

Loopback Address(RFC4291)

• ::1/128

Unspecified Address(RFC4291)

• ::/128

IPv4-IPv6 Translat/IPv4-Embedded IPv6 Address(RFC6052)

• 64:ff9b::/96

IPv4射影アドレス/IPv4-Mapped IPv6 Address(RFC4291)

• ::ffff:0:0/96

Discard-Only Address Block(RFC6666)

• 100::/64

IETF Protocol Assignments(RFC2928)

• 2001::/23

TEREDO(RFC4380)

• 2001::/32

Benchmarking(RFC5180)

• 2001:2::/48

Documentation(RFC3849)

• 2001:db8::/32

ORCHID(RFC4843)

• 2001:10::/28

6to4(RFC3056)

• 2002::/16

Unique-Local(RFC4193)

• fc00::/7

Linked-Scoped Unicast(RFC4291)

• fe80::/10

IPv4の色々なアドレスについて(覚書)

もうグローバルアドレスとしては在庫がなくなっているIPv4ですが、いくつかある特殊なアドレスが今どうなっているか確認したので覚書。

IPv4のPrivate Address
RFC1918 Address Allocation for Private Internets[1]

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

IPv4のISP Shared Address(LSN用)
RFC6598 ISP Shared Address[2]

•  100.64.0.0/10

IPv4のLink Local Address
RFC6890 Special-Purpose IP Address Registries[3]

• 169.254.0.0/16

他にも色々な定義がRFC6890にある。

[1] http://tools.ietf.org/html/rfc1918
[2] http://tools.ietf.org/html/rfc6598
[3] http://tools.ietf.org/html/rfc6890

俺の俺による俺のためのARM Cortexシリーズまとめ(~A57/A53まで)

わからない・・・
ARMといえばアプリケーションプロセッサとしてのCortex-Aシリーズがすっかりガジェット好きの間でプレゼンスを広げていると思いますが、あまりにナンバリングが不規則で(マーケティング上の理由だと思いますが)、特にハイエンド以外で新しいアーキテクチャがよくわからないので、あくまで自分用に纏めようと一念発起してみました。

こうなってるよ！！
このエントリーが公開されて、この項が書かれているということは、自分の中での整理もひと通り済んでいるはずですｗ
また、発表時期は並んでいますが縦軸はあくまでイメージです。ご了承ください。

ちなみにこれ以降は時系列順(発表順)に記載します。

Cortexシリーズ前夜
ARM6、ARM7(E)、ARM9(E)、ARM11(E)等々。今でもARM9とかは組み込みプロダクトで目にします。消費電力とライセンス代の兼ね合いでしょうか。

Cortex-A8(2005/10/08発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a8.php
http://www.arm.com/about/newsroom/10548.php

• 最初のCortex-Aシリーズ
• 命令セットはARMv7
• クロックは600MHz-1GHz
• スーパースカラー並列処理(2命令)
• 13段パイプライン/インオーダー実行
• VFPv3
• Thumb-2
• NEON
• Jazelle RCT
• 統合L2キャッシュ(0-4MB)
• 2.0DMIPS/MHz
• プロセスルール65nm
• 消費電力300mW以下
• 「5年にわたって基準になるマイクロプロセッサ」[1]

Cortex-A8の採用プロダクト

• Allwinner A1X
• Freescale i.MX51
• Rockchip RK2918, RK2906
• Samsung Exynos 3110
• TI OMAP 3
• TI Sitara ARM MPU AM3x
• Conexant CX92755
• Samsung S5PC100

Cortex-A9(2007/10/03発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a9.php
(PDF) http://www.arm.com/files/pdf/ARMCortexA-9Processors.pdf

• マルチコア構成を取る場合は「Cortex-A9 MPCore」という。MPCoreの場合はコア数1-4。
• 命令セットはARMv7
• クロックは特に記載なし。
• スーパースカラー複数処理
• 8段パイプライン/アウトオブオーダー実行
• Thumb-2
• NEONがオプションに
• VFPv3浮動小数点演算(オプション、以前のものより高速)
• TrustZoneセキュリティ拡張
• JazelleDBXサポート(Javaバイトコード実行用)
• Jazelle RCT
• 2.50DMIPS/MHz/core　ハイエンドでは1500-3000DMIPS、単機能向けに600-900DMIPS
• 最適化L1キャッシュ
• L2キャッシュ(0-4MB)
• PrimeCell PL310 L2キャッシュコントローラ(-8MB)

Cortex-A9の採用プロダクト

• Altera Cyclone V
• Altera Arria V
• AmLogic AML8726-M
• Broadcom BCM11311
• Calxeda EnergyCore ECX-1000
• Freescale i.MX6
• HiSilicon K3V2(Hi3620)
• HiSilicon K3V2E
• HiSilicon Kirin 910
• HiSilicon Kirin 910T
• Leadcore LC1810, LC1811
• MediaTek MT6575, MT6577, MT6575M, MT6577T, MT6517, MT6517T
• Nufront Nusmart 2816, 2816M, 115
• nVidia Tegra2
• nVidia Tegra3
• Trident Microsystems 847x/8x/9x SoC family(謎)
• ルネサスエレクトロニクス EMMA Mobile/EV2
• Rockchip RK3066, RK292x, RK31xx
• Samsung Exynos 4210, 4212, 4412
• Sony PlayStation Vita
• STMicroelectronics SPEAr1310, SPEAr1340
• ST-Ericsson Nova A9500, NovaThor U8500, NovaThor U9500
• TI OMAP4
• Xilinx Extensible Processing Platform
• ZiiLABS ZMS-20
• Apple/Samsung S5L8940, S5L8942
• Apple/Samsung A5X

以上Wikipedia(en)より。他にもいっぱいありそう



Cortex-A5(2009/10/22発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a5.php

• 低コスト、最高のエネルギー効率
• ARM9(ARM926EJ-S)、ARM11(ARM1176JZ-2)からの移行
• ARMv7アプリケーションに対する互換性(Cortex-A8、Cortex-A9、古いARM)
• 1〜4コア
• インオーダーパイプライン
• 1.57DMIPS
• DMIPSはARM926の1.9倍？、MHzあたりの消費電力はARM926よりも低い、Core面積はARM926よりもほんの少し大きい。またこれら指標は３つすべてARM1176より優れているので置き換え需要がある？
• Thumb-2
• DSP&SIMD拡張
• VFPv4(オプション)
• NEON(オプション)
• Jazelle DBX,RCT
• TrustZone

Cortex-A5の採用プロダクト

• Qualcomm Snapdragon S1のうち MSM7225A/MSM7625A/MSM7227A/MSM7627A/MSM7225AB
• Qualcomm Snapdragon S4 Play MSM8225/MSM8625/MSM8225Q/MSM8625Q
• Qualcomm Snapdragon 200のうち MSM8225Q/MSM8625Q
• Spectrum SC8810
• AMD Fusionの将来のモデル(でキュリティコプロセッサとしてTrustZoneを使用)
• Telechips TCC8923

Cortex-A15(2010/09/09発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a15.php

• マルチコア構成だと「Cortex-A15 MPCore」？コア数1〜4？
• 命令セットはARMv7
• クロックは特に記載なし(ただし、想定ではモバイルの1〜1.5GHz 1or2コアからWebサーバ、無線インフラの2.5GHzの4コア)
• プロセスルールは20nm
• ハードウェア仮想化
• 40bit物理アドレス拡張LPAEにより最大1TBのRAMにアクセス可能(スレッド単位では最大32bitアドレス)
• スーパースカラー並列(3並列)処理
• 整数15段、浮動小数演算17〜25段パイプライン/アウトオブオーダー実行
• Thumb-2
• NEON
• DSP/NEON per core
• VFPv4浮動小数演算 per core
• TrustZoneセキュリティ拡張
• Jazelle RCT
• 32kBデータ+32kB命令統合L1キャッシュ
• 低レイテンシ最大4MBperクラスタ 統合L2キャッシュ

PDFがないっぽくてあまり正確な情報がわからない

Cortex-A15の採用プロダクト

• Broadcom SoC
• nVidia Tegra4
• Samsung Exynos 5250
• ST-Ericsson Nova A9600
• TI OMAP5
• AllWinner A80(Cortex-A15/Cortex-A7)
• HiSilicon Kirin 920(Cortex-A15/Cortex-A7)
• HiSilicon Kirin 925(Cortex-A15/Cortex-A7)

Cortex-A7(2011/10/19発表)
http://www.arm.com/ja/products/processors/cortex-a/cortex-a7.php

• 複数コア構成の場合は「Cortex-A7 MPCore」？
• Cortex-A15のコンパニオンプロセッサとして、「big.LITTLE」構成を提案
• ハードウェア仮想化
• 40bit物理アドレス拡張LPAE
• 命令セットはARMv7
• コア数1〜4
• Thumb-2
• NEON
• DSP&SIMD
• VFPv4
• Jazelle RCT
• 最適化L1キャッシュ
• 統合L2キャッシュ(オプション)
• 8ステージパイプライン インオーダー
• 部分的2並列
• TrustZone
• 1.9 DMIPS

Cortex-A15と同じ機能を持ちながら、電力効率を優先して性能を抑え目に。

Cortex-A7の採用プロダクト

• MediaTek MT6589
• AllWinner A80(Cortex-A15/Cortex-A7)
• AllWinner A20
• AllWinner A23
• AllWinner A31
• AllWinner A31s
• AllWinner A33
• AllWinner A83T
• AllWinner H3
• AllWinner H8
• AllWinner R16
• AllWinner R58
• AllWinner T2
• AllWinner T8
• AllWinner V3
• AllWinner V3s
• AllWinner V10
• Leadcore LC1813/LC1913/LC1860/LC1860C/LC1960
• MediaTek MT6572/MT6572M/MT6571/MT6589/MT6589M/MT6589T/MT6582/MT6582M/MT6588/MT6592/MT6592M/MT6591/MT6595(Cortex-A17/Cortex-A7)/MT6595M(Cortex-A17/Cortex-A7)/MT6595Turbo(Cortex-A17/Cortex-A7)
• Qualcomm Snapdragon 400のうち MSM8026/MSM8226/MSM8228/MSM8626/MSM8628/MSM8926/MSM8928
• Qualcomm Snapdragon 210 MSM8909
• Qualcomm Snapdragon 212
• Qualcomm Snapdragon 208 MSM8208
• Qualcomm Snapdragon 200のうち MSM8210/MSM8610/MSM8212/MSM8612

Cortex-A57(2012/10/30発表)
http://www.arm.com/ja/products/processors/cortex-a50/cortex-a57-processor.php

• 命令セットはARMv8
• 1-4対称コアクラスタ
• AArch32(ARMv7完全互換)
• AArch64
• TrustZone
• NEON
• DSP&SIMD
• VFPv4
• ハードウェア仮想化
• ハードウェア暗号化
• 4GBの物理アドレスへのアクセス
• 64bitの仮想アドレスへのアクセス(AArch64)
• 最適化L2キャッシュ
• 深いアウトオブオーダーパイプライン
• TBD(まとまった資料と時間が見つかったら更新)

Cortex-A57の採用プロダクト

• Qualcomm Snapdragon 810 MSM8994(Cortex-A57/Cortex-A53)
• Qualcomm Snapdragon 808 MSM8992(Cortex-A57/Cortex-A53)

Cortex-A53(2012/10/30発表)
http://www.arm.com/ja/products/processors/cortex-a50/cortex-a53-processor.php

• 命令セットはARMv8
• 1-4対称コアクラスタ
• AArch32(ARMv7完全互換)
• AArch64
• TrustZone
• NEON
• DSP&SIMD
• VFPv4
• ハードウェア仮想化
• ハードウェア暗号化
• 4GBの物理アドレスへのアクセス
• 64bitの仮想アドレスへのアクセス(AArch64)
• インオーダーパイプライン
• TBD

Cortex-A53の採用プロダクト

• Qualcomm Snapdragon 810 MSM8994(Cortex-A57/Cortex-A53)
• Qualcomm Snapdragon 808 MSM8992(Cortex-A57/Cortex-A53)
• Qualcomm Snapdragon 620 MSM8976(Cortex-A72/Coretx-A53)
• Qualcomm Snapdragon 618 MSM8956(Cortex-A72/Coretx-A53)
• Qualcomm Snapdragon 617 MSM8952
• Qualcomm Snapdragon 616 MSM8939v2
• Qualcomm Snapdragon 615 MSM8939
• Qualcomm Snapdragon 610 MSM8936
• Qualcomm Snapdragon 430 MSM8937
• Qualcomm Snapdragon 415 MSM8929
• Qualcomm Snapdragon 412 MSM8916v2
• Qualcomm Snapdragon 410 MSM8916
• AllWinner A53
• AllWinner H64
• MediaTek MT6732 MT6732M MT6735 MT6735P MT6735M MT6752 MT6752M  MT6753
• MediaTek Helio P10; MT6755
• MediaTek Helio X10; MT6795
• MediaTek Helio X20; MT6797(Cortex-A72/Cortex-A53)
• HiSilicon Kirin 620
• HiSilicon Kirin 930
• HiSilicon Kirin 935
• HiSilicon Kirin 950(Cortex-A72/Cortex-A53)

別エントリにて各SoCの製造メーカーについて。

[1] http://www.itmedia.co.jp/news/articles/0510/26/news120.html

テスト投稿(日付フォーマット)

W3CDTFというフォーマットがあり、以下の６タイプが規定されている。

1. 年のみ YYYY（例：2001）
2. 年月 YYYY-MM（例：2001-08）
3. 年月日 YYYY-MM-DD（例：2001-08-02）
4. 年月日および時分 YYYY-MM-DDThh:mmTZD（例：2001-08-02T10:45+09:00）
5. 年月日および時分秒 YYYY-MM-DDThh:mm:ss.sTZD（例：2001-08-02T10:45:23.5+09:00）
6. 年月日および時分秒および小数部分 YYYY-MM-DDThh:mm:ss.sTZD（例：2001-08-02T10:45:23.5+09:00）

TZDにはUTCからの時差を示すか、UTCの場合はZの一文字を記述する。
XML SchemaのXSDTYPEは、上記のうちの5と6が使用可能である。(ただし、TZD部分は省略可能)


参考：http://www.kanzaki.com/docs/html/dtf.html