コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2020年9月3日 >>> 2020年8月25日
link もっと後

2020年9月3日

FreeRTOSで遊ぼう その1 - FreeRTOS入門

目次: FreeRTOS

以前RTOS界の新星Zephyrを調べて、新たなRISC-Vボードの定義を作りました。今回はRTOSの老舗FreeRTOSを調べます。FreeRTOSはGPLv2で開発されていましたが、Amazonが買収した後はMITライセンスになっています。IoT分野での企業ユーザー(大抵コード公開を嫌がる)を重視したんでしょう。

FreeRTOSのコード取得
$ git clone https://github.com/FreeRTOS/FreeRTOS freertos

Cloning into 'freertos'...
remote: Enumerating objects: 149823, done.
Receiving objects:   0% (1/149823)
remote: Total 149823 (delta 0), reused 0 (delta 0), pack-reused 149823
Receiving objects: 100% (149823/149823), 115.38 MiB | 8.29 MiB/s, done.
Resolving deltas: 100% (107018/107018), done.
Updating files: 100% (12962/12962), done.

$ git submodule update --init --recursive

FreeRTOSのカーネルはFreeRTOS/Sourceに配置されており、リポジトリはhttps://github.com/FreeRTOS/FreeRTOS-Kernelです。

FreeRTOS上で動く何かを作成する場合はfreertos/FreeRTOS/Demoの下に作るルールになっているようです。たくさんのアーキテクチャ、ボード向けのコードが格納されています。統一感がなくて、どれを見たら良いのか良くわからないのが難点です。

ツールチェーンの準備

RISC-V 32ビット用でしたら、以前Zephyr用に作成したツールチェーン2020年1月31日の日記参照)が流用できます。ARMやそれ以外の環境でもCrosstool-NGを使えばたいてい作成できるはずです。

既存のデモを作り変える

Demoディレクトリの下にはRISC-V QEMU向けのプロジェクト(正確にはSiFive HiFive1エミュレーション環境向け)が既に1つあります。FreeRTOS/Demo/RISC-V-Qemu-sifive_e-Eclipse-GCCです。このデモはEclipse向けになっているので、Makefile向けに作り直します。Eclipse関連のファイルを削除してMakefileを作成するだけです。

Makefile

CROSS=riscv64-unknown-elf-
CC=$(CROSS)gcc
OBJCOPY=$(CROSS)objcopy
ARCH=$(CROSS)ar

RTOS_SOURCE_DIR=../../Source
DEMO_SOURCE_DIR=../Common/Minimal
LIBWRAP_SOURCE_DIR=./freedom-e-sdk/libwrap

CPPFLAGS = -g -O2 -Wall -march=rv32ima -mabi=ilp32 -mcmodel=medlow \
	-fmessage-length=0 \
	-ffunction-sections \
	-fdata-sections \
	-fno-builtin-printf \
	-DportasmHANDLE_INTERRUPT=handle_trap \
	-I . -I ../Common/include \
	-I $(RTOS_SOURCE_DIR)/include \
	-I $(RTOS_SOURCE_DIR)/portable/GCC/RISC-V \
	-I $(RTOS_SOURCE_DIR)/portable/GCC/RISC-V/chip_specific_extensions/RV32I_CLINT_no_extensions \
	\
	-I freedom-e-sdk/include \
	-I freedom-e-sdk/env \
	-I freedom-e-sdk/env/freedom-e300-hifive1

CFLAGS =
ASFLAGS =
LDFLAGS = \
	-march=rv32ima -mabi=ilp32 -mcmodel=medlow \
	-Tfreedom-e-sdk/env/freedom-e300-hifive1/flash.lds \
	-Xlinker --gc-sections \
	-Xlinker --defsym=__stack_size=300

SRCS = \
	main.c \
	blinky_demo/main_blinky.c \
	$(DEMO_SOURCE_DIR)/EventGroupsDemo.c \
	$(DEMO_SOURCE_DIR)/TaskNotify.c \
	$(DEMO_SOURCE_DIR)/TimerDemo.c \
	$(DEMO_SOURCE_DIR)/blocktim.c \
	$(DEMO_SOURCE_DIR)/dynamic.c \
	$(DEMO_SOURCE_DIR)/recmutex.c \
	$(RTOS_SOURCE_DIR)/event_groups.c \
	$(RTOS_SOURCE_DIR)/list.c \
	$(RTOS_SOURCE_DIR)/queue.c \
	$(RTOS_SOURCE_DIR)/stream_buffer.c \
	$(RTOS_SOURCE_DIR)/tasks.c \
	$(RTOS_SOURCE_DIR)/timers.c \
	$(RTOS_SOURCE_DIR)/portable/MemMang/heap_4.c \
	$(RTOS_SOURCE_DIR)/portable/GCC/RISC-V/port.c

ASMS = \
	$(RTOS_SOURCE_DIR)/portable/GCC/RISC-V/portASM.S \
	\
	freedom-e-sdk/env/start.S \
	freedom-e-sdk/env/entry.S

OBJS = $(SRCS:.c=.o) $(ASMS:.S=.o)

a.out: $(OBJS) $(CRT0) Makefile
	$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -nostartfiles $(CRT0) $(LINKER_FLAGS) -o $@

clean:
	rm -rf $(OBJS)

元のコードでは --defsym=__stack_size=350なんですが、そのまま使うとなぜか下記のリンクエラーが出るので、少しだけ減らしています。

__stack_size=350のときのリンクエラー
x-tools/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: section .stack VMA [0000000080003e00,0000000080003fff] overlaps section .bss VMA [0000000080000440,0000000080003ebb]
collect2: error: ld returned 1 exit status
make: *** [Makefile:105: rtosdemo.elf] Error 1

リンカースクリプトを見る限りHiFive1はRAMが16KBしかないようで、あまり大きな領域を取ろうとするとすぐに溢れてしまいます。

リンカースクリプト

// freertos/FreeRTOS/Demo/RISC-V-Qemu-virt_GCC/freedom-e-sdk/env/freedom-e300-hifive1/flash.lds

MEMORY
{
  flash (rxai!w) : ORIGIN = 0x20400000, LENGTH = 512M
  ram (wxa!ri) : ORIGIN = 0x80000000, LENGTH = 16K
}

Makefileを作ったらmakeし、動作確認します。

動作確認
$ qemu-system-riscv32 -nographic -machine sifive_e -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -bios none -kernel a.out

StartingBlink
Blink
Blink
Blink
Blink
...

動作しました。QEMUを止めるまでBlinkという文字が延々と出続けます。最初のStartingに改行が入っていないのは元々です。理由は良くわかりません、作った人がミスっただけかな?

編集者:すずき(2023/09/24 08:51)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年9月2日

Zephyrの16550シリアルドライバ その2

目次: Zephyr

以前、RISC-V QEMUの -machine virtで、シリアルドライバ16550を使う設定を作りましたが、Zephyr 2.3.0で動かなくなってしまいました。悲しい。

変更点はレジスタアドレスシフト量の設定方法です。DT_NS16550_REG_SHIFTで設定する方式でしたが、デバイスツリーから設定するように変更されました。

NS16550のコードを変えているZephyr本家のコミット
commit 70a0063b69b06812c5726077646cffae3b8e199c
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Fri Mar 27 06:03:59 2020 -0500

    drivers: serial: uart_ns16550: Convert to new DT_INST macros

    Convert older DT_INST_ macro use the new include/devicetree.h
    DT_INST macro APIs.

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
NS16550のコードの変更内容

// zephyr/drivers/serial/uart_ns16550.c

-#ifdef DT_INST_0_NS16550_REG_SHIFT
-#define UART_REG_ADDR_INTERVAL (1<<DT_INST_0_NS16550_REG_SHIFT)
+#if DT_INST_NODE_HAS_PROP(0, reg_shift)
+#define UART_REG_ADDR_INTERVAL (1<<DT_INST_PROP(0, reg_shift))
 #endif

デバイスツリーに何を書けば良いのかは、デバイスツリーのドキュメント(ns16550.yaml)を見ましょう。プロパティ名と説明が書いてあります。

デバイスツリーの変更内容

// zephyr/dts/bindings/serial/ns16550.yaml

properties:
    reg:
      required: true

    reg-shift:
      type: int
      required: false
      description: quantity to shift the register offsets by


// zephyr/dts/riscv/riscv32-virt.dtsi

...

		uart0: serial@10000000 {
			compatible = "ns16550";
			reg = <0x10000000 0x100>;
			clock-frequency = <3686400>;
			label = "uart_0";
			current-speed = <115200>;
			reg-shift = <0>;    /* ★これを追加★ */
		};


// zephyr/soc/riscv/riscv-privilege/rv32-virt/soc.h

...

/* ★★下記定義は全て不要★★ */

#define DT_UART_NS16550_PORT_0_BASE_ADDR    DT_INST_0_NS16550_BASE_ADDRESS
#define DT_UART_NS16550_PORT_0_BAUD_RATE    DT_INST_0_NS16550_CURRENT_SPEED
#define DT_UART_NS16550_PORT_0_CLK_FREQ     DT_INST_0_NS16550_CLOCK_FREQUENCY
#define DT_UART_NS16550_PORT_0_NAME         DT_INST_0_NS16550_LABEL

#define DT_NS16550_REG_SHIFT                0

以上の修正を入れて動かします。

動作確認

$ qemu-system-riscv32 -nographic -machine virt -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build zephyr-v2.3.0-2350-g2f294fcc2da8  ***               
Hello World! QEMU RV32 virt board

動きました。良かった良かった。

編集者:すずき(2023/09/24 12:07)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年9月1日

Zephyr OSで遊ぼう その11 - Zephyr 2.3.0に対応する

目次: Zephyr

Zephyr 2.3.0にバージョンアップしたところ、またHogeボードのビルドが通らなくなりました。

一点目はUARTドライバのCMakeListsです。zephyr_library_sources_if_kconfig() がなくなったため、書き方が変わりました。

CMakeListsの書き方が変わったZephyr本家のコミット
commit 244f826e3c7333bb92fb53a65c50ee5cbd8a2ea0
Author: Carles Cufi <carles.cufi@nordicsemi.no>
Date:   Fri Jul 31 13:52:40 2020 +0200

    cmake: remove _if_kconfig() functions

    This set of functions seem to be there just because of historical
    reasons, stemming from Kbuild. They are non-obvious and prone to errors,
    so remove them in favor of the `_ifdef()` ones with an explicit
    `CONFIG_` condition.

    Script used:

    git grep -l _if_kconfig | xargs sed -E -i
    "s/_if_kconfig\(\s*(\w*)/_ifdef(CONFIG_\U\1\E \1/g"

    Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
CMakeListsの書き方を変更

# drivers/serial/CMakeLists.txt

zephyr_library_sources_if_kconfig(uart_spike.c)

下記に変更

zephyr_library_sources_ifdef(CONFIG_UART_SPIKE uart_spike.c)

二点目は整数型です。Zephyrはu8_t, u16_t, u32_tのような独自の整数型を持っていましたが、C99の型に置き換えられました。drivers/serial/uart_spike.cの実装を書き換える必要があります。

C99の型に置き換えたZephyr本家のコミット
commit a1b77fd589dbe7284c17b029f251426a724abd47
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Wed May 27 11:26:57 2020 -0500

    zephyr: replace zephyr integer types with C99 types

            git grep -l 'u\(8\|16\|32\|64\)_t' | \
                    xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g"
            git grep -l 's\(8\|16\|32\|64\)_t' | \
                    xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g"

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

三点目はDT_INST_0_SPIKE_UART_SPIKE_LABELマクロです。こいつは元々、訳のわからない名前で直しようがないので、SiFiveのシリアルドライバの履歴を参考に直します。履歴を見ると2回ほど変わっています。

マクロ名のルールはDT_INST_<INSTANCE>_<COMPAT>_<PROP> だったみたいです。今初めて知りました。やっぱりこの書き方は意味不明と思ったのか、DT_INST_PROP(0, label) という形式になりました。さらに今はDT_INST_LABEL(0) という形式に落ち着いています。

マクロ名の変更を行ったZephyr本家のコミット
★★DT_INST_PROP(0, label) になったコミット

commit 8f84520130a346957ac2e2bdff1d6a51bca13af0
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Tue Mar 10 17:24:43 2020 -0500

    drivers: serial: uart_sifive: convert to new DT API

    Use the new devicetree.h API instead of the legacy macros.

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>


★★DT_INST_LABEL(0) になったコミット

commit 74d459fb66b10a5a0614a582fb0375d8b4a78c9e
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Thu Apr 2 13:13:47 2020 -0500

    drivers: serial: sifive: use DT_INST_LABEL macro

    Replace a few cases that should have been DT_INST_LABEL instead.

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

このマクロの罠はそれだけに留まらず、ソースコードの先頭に下記マクロを定義する必要があります。依然として訳がわかりません。ZephyrはDviceTree周りの仕様が不安定です。

ソースコードの先頭に必要なマクロ定義

// zephyr/drivers/serial/uart_spike.c

#define DT_DRV_COMPAT spike_uart_spike

最後はリンカーです。これは元々のコードのコンフィグが間違っていたことに起因します。ROM領域がないのにCONFIG_XIPが有効になっていました。

リンクエラー
$ ninja

...

x-tools/riscv64-zephyr-elf/lib/gcc/riscv64-zephyr-elf/8.3.0/../../../../riscv64-zephyr-elf/bin/ld: invalid origin for memory region ROM
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

エラーメッセージからは何が原因か読み取れないですね。こういうときはビルドディレクトリのリンカースクリプト(zephyr/linker.cmd)をうまく行く場合と、うまく行かない場合で見比べます。

リンクエラーが起きないとき(qemu_riscv32)のリンカースクリプト

/* zephyr/build/zephyr/linker.cmd */

 OUTPUT_ARCH("riscv")
 OUTPUT_FORMAT("elf32-littleriscv")
MEMORY
{
    ROM (rx) : ORIGIN = 541065216, LENGTH = 12582912
    RAM (rwx) : ORIGIN = 0x80000000, LENGTH = ((16) << 10)
    IDT_LIST (wx) : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}
リンクエラーが起きるとき(Hogeボード)のリンカースクリプト

/* zephyr/build/zephyr/linker.cmd */

 OUTPUT_ARCH("riscv")
 OUTPUT_FORMAT("elf32-littleriscv")
MEMORY
{
    ROM (rx) : ORIGIN = ROM_BASE, LENGTH = ROM_SIZE    /* ★★ここがおかしい★★ */
    RAM (rwx) : ORIGIN = 0x80000000, LENGTH = ((32) << 10)
    IDT_LIST (wx) : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

このスクリプトは下記のファイルから生成されているようです。HogeボードはROM領域を使う前提ではないので、領域そのものが要りません。ROM領域を葬るにはCONFIG_XIPをnにすれば良さそうです。ファイルはboards/riscv/hoge/hoge_defconfigです。

RISC-Vのリンカースクリプト

// include/arch/riscv/common/linker.ld

MEMORY
{
#ifdef CONFIG_XIP
#if DT_NODE_HAS_COMPAT_STATUS(DT_CHOSEN(zephyr_flash), soc_nv_flash, okay)
#define ROM_BASE DT_REG_ADDR(DT_CHOSEN(zephyr_flash))
#define ROM_SIZE DT_REG_SIZE(DT_CHOSEN(zephyr_flash))
#elif DT_NODE_HAS_COMPAT_STATUS(DT_CHOSEN(zephyr_flash), jedec_spi_nor, okay)
/* For jedec,spi-nor we expect the spi controller to memory map the flash
 * and for that mapping to be the second register property of the spi
 * controller.
 */
#define SPI_CTRL DT_PARENT(DT_CHOSEN(zephyr_flash))
#define ROM_BASE DT_REG_ADDR_BY_IDX(SPI_CTRL, 1)
#define ROM_SIZE DT_REG_SIZE_BY_IDX(SPI_CTRL, 1)
#endif
    ROM (rx)  : ORIGIN = ROM_BASE, LENGTH = ROM_SIZE    /* ★★CONFIG_XIPが無効ならこの行ごと消える★★ */
#endif
    RAM (rwx) : ORIGIN = CONFIG_SRAM_BASE_ADDRESS, LENGTH = KB(CONFIG_SRAM_SIZE)
    /* Used by and documented in include/linker/intlist.ld */
    IDT_LIST  (wx)      : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

以上の修正を入れて動かします。

動作確認
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build zephyr-v2.3.0-2349-g0769bb760b2a  ***
Hello World! hoge

やっと動きました。良かった良かった。

編集者:すずき(2023/09/24 12:06)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年8月31日

Zephyr OSで遊ぼう その10 - QEMUの変化に対応する

目次: Zephyr

最近のRISC-V向けQEMUでspike, virtを起動すると、下記のようなエラーで怒られてしまいます。

QEMU RISC-Vの起動時に出るエラー
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf

qemu-system-riscv32: Unable to load the RISC-V firmware "opensbi-riscv32-spike-fw_jump.elf"

このエラーの原因はQEMU RISC-V向けの仕様変更によるものです。machineがspike, virtのときに、自由にBIOSを選べるように変わりました。ですがZephyrを起動する際には、特にBIOSは必要ないため、noneを指定すればOKです。

QEMU RISC-VをBIOSなしで起動する
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build v2.2.0-rc1-123-gcaca3f60b012  ***
Hello World! hoge

ZephyrだけでなくQEMUも日々進化しているのですね。

編集者:すずき(2023/09/24 12:06)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年8月30日

自宅駐車場でのもらい事故

目次:

先週、突然知らない番号から電話が掛かってきました。何だか焦った様子でした。要約すると「アパートの駐車場で隣に駐車している者です、駐車しようとして、あなたの車にぶつけてしまいました」とのことでした。車の様子を確認したところ、見事にバンパーの右前が取れていました。ああー……。


レガシィのバンパーが取れた

後日、保険屋さんと修理屋さん(スーパーオートバックス)から電話があり、車を引き取りに来る日時等を決めました。そして今日、レガシィさんはフロントバンパー修理のため旅立っていきました。

修理屋さん曰く「右ライトもAssy交換で新品になるだろう」とのこと。新品交換後の右ライトに対し、古ぼけた左ライトの明るさがアンバランスになるのはうまくないので、左ライトの研磨もお願いしました。残念ながら左ライトの研磨は保険が効かず自費になりそうですが、曇っていたライトが明るくなるから良しとしましょう。

代車

代車はホンダのフィットでした。


代車のフィット、外観


代車のフィット、インパネ

総じて良い車だと思います。レガシィとの違いとしては、

  • フロントがかなり斜めってる、真上の日差しがダッシュボードを照らし前が見えない
  • アクセルがフニャフニャ、踏んでもあまり速度が変わらない(遊びが大きい??)
  • ブレーキがある点から急激に効いて怖い

昔のフィットに乗ったときアクセルオフ時のエンブレが急すぎて車酔いしたので、正直好きな車ではなかったのですが、今のフィットは素敵な車です。新しい車って確実に良くなってますね。

ADAS(前車の車間検知、車線逸脱の警告)も搭載されていて面白いです。たまに誤検知?するのか、何もないところで突然ピー!と警告音が鳴ったり、車線逸脱の警告とともにハンドルがンゴゴー!って言い出すのはご愛敬です。

編集者:すずき(2023/09/30 14:51)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年8月29日

ROCK64をRaspberry Pi 3のケースに無理やり格納

目次: ROCK64/ROCKPro64

先日KADHAS VIM2, VIM3を購入したため、ARMボードがさらに増え置き場がなくなりました。既存のボードをコンパクトに収納できないかと画策し、目を付けたのがROCK64です。現在ROCK64は純正ケースに入れて使っていますが、ギリシャの神殿を思わせる立派な柱と、無駄にでかいアクリル板のせいで、すっっごい邪魔です。


ROCK64の純正ケース

ROCK64はRaspberry Pi 3とほぼ同じ大きさですから、Raspberry Pi 3のケースを流用できるはずです。

ケース選び

改造のベースになるケースは、TinkerBoardやRaspberry Pi 3の格納で活躍しているPhysical Computing Labの3ple Decker Raspberry Piケース(公式サイトへのリンク)です。

Rasberry Pi 3は電源がUSB micro Bですが、ROCK64はACアダプタなので、全く形が合いません。アクリルケースの穴を削って広げる必要があります。もう一か所、ROCK64の個体差か(or単に設計の問題か?)ヘッドホンジャックがケースとズレていて、プラグが刺さらないため、これも直さないといけません。


電源コネクタ周辺(削る予定の部分を黒く塗っている)


ヘッドホンジャック周辺(削る予定の部分を黒く塗っている)

削り方はリューターにプラスチック用のビットを付けてゴリゴリ削るだけです。厚さも面積も大したことないので、力業でどうにでもなると思います。アクリルを削ると変なにおいがしますね。焦げてるのかな……?


加工後のケース

ケースを削り終わりました。ROCK64の端子がちゃんと外から見えています。

細かい不都合

元よりROCK64用のケースではないので、様々な不都合が発生します。

  • ROCK64の22pinのピンヘッダ(Pi P5+ Bus)がケースで隠れて配線できない
  • ROCK64のPWR, RESETボタンが押せない
  • ボードの固定が甘くなる

Pi P5+ Busが使用不能になる点は諦めました。Rasberry Pi 3にはないピンヘッダなので致し方無しです。このピンヘッダから引き出していたS/PDIFが利用不可能になりました。さよならS/PDIFさん。

PWR, RESETボタンはケースを開ければ押せますが、面倒です。今後はPWRボタンに頼らない運用を考えるべきでしょう。

ボードが固定できない問題はどうにもなりませんでした。microSDの上部を抑えるケース側のツメがうまくハマりません。


ボードを固定するケース側のツメ

もう少しきちんと調べてみると、ROCK64はRasberry Pi 3よりmicroSDスロットに厚みがあるせいで、microSDの上部を抑えるケース側のツメがうまくハマらないようです。


Raspberry Pi 3の場合


ROCK64の場合

スロットの厚さはどうしようもないので、泣く泣くケース側のツメを折りました。

ツメがないので、microSDカードがケースに引っ掛かってギリギリケースに固定されている状態です。ROCK64の40pinのピンヘッダ(Pi-2 Bus)にジャンパケーブルを抜き差しすると、microSDにかなり力が掛かります。これは良くないですね……。

Pi-2 Busへのケーブル抜き差しは結構固いため、そのうちmicroSDスロットが変形するか、microSDが折れて壊れると思います。幸いなことに、今は頻繁にピンヘッダのケーブル抜き差しはしませんから、しばらくこの状態でも使えるでしょう。

編集者:すずき(2020/10/30 01:22)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2020年8月27日

サーバ向けプロセッサでは最強のIntel

目次: ROCK64/ROCKPro64

TwitterでCavium Thunder X3はサーバ向け汎用ARM SoCではなくなるかもしれない、という話を見かけました。Cavium(今はMarvellに買収されました)は独自ARM CPUコアを作って頑張ってたメーカーです。

ARM自体はまだまだめげることなく、サーバ向けに売りたい(Armのサーバ向け戦略十年の計は実を結ぶか、新プロセッサ「Neoverse」 - MONOist)ようですが、肝心のARM系SoCメーカーやサーバベンダーがARM系サーバで成功している様子がないです。

以前Qualcomm Centriqも鳴り物入りでサーバ向けARM SoCに参入しましたが、2018年にあっさり撤退Arm SoCの開発部門を秘かに閉鎖していたQualcomm - EE Times Japan)しています。モバイルの王者Qualcommをもってしても困難な道のようです。

サーバ向けプロセッサはIntelが9割取っているらしいので、崩すのはなかなか容易ではありませんね……。

ARMメニーコア系SoC

サーバ向けとして発表されているARMメニーコア系SoCを列挙してみました。年代はチップがローンチされたおおよその時期です。間違ってたらごめんなさい。

  • Ampere Altra(2020, ARM Neoverse N1, 80コア, 7nm)
  • Amazon Graviton 2(2020, ARM Neoverse N1, 64コア, 7nm)
  • Huawei Kunpeng 920(2019, Hisilicon TSV110, 64コア, 7nm)
  • Cavium Thunder X2(2018, Broadcom Vulkan, 32コア, 14nm)
  • Amazon Graviton(2018, ARM Cortex-A72, 16コア, 16nm)
  • Qualcomm Centriq(2017, Qualcomm Folker, 48コア, 10nm)
  • Socionext SC2A11(2017, Cortex-A53, 24コア)
  • Cavium Thunder X1(2014, Cavium独自, 48コア)

こんな感じですかね?SC2A11はホームページでサーバ向けと謳っていたので、リストに入れてます。でもCA53コアなので、性能的にはThunder X2辺りと並べるのはちょっと厳しい……かな?

編集者:すずき(2023/09/24 12:54)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2020年9月3日 >>> 2020年8月25日
link もっと後

管理用メニュー

link 記事を新規作成

<2020>
<<<09>>>
--12345
6789101112
13141516171819
20212223242526
27282930---

最近のコメント20件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」
  • link 24年1月24日
    すずきさん (02/13 11:48)
    「ありがとうございます。\n私のPCはもう...」
  • link 24年1月24日
    えはらさん (02/12 15:00)
    「Powershellのスクリプトは以下の...」
  • link 24年2月2日
    すずきさん (02/02 18:17)
    「サーバー側の設定はとても簡単でした。ちょ...」
  • link 24年2月2日
    hdkさん (02/02 08:54)
    「さくらのレンタルサーバの設定でLet's...」
  • link 24年1月24日
    すずきさん (01/28 11:35)
    「ご指摘ありがとうございます。確かに間違っ...」
  • link 24年1月24日
    通りすがりさん (01/27 14:05)
    「Powershellで解決しなかったのは...」
  • link 23年11月29日
    すずきさん (12/04 00:38)
    「あ、そうか。1nsですね。ありがとうござ...」
  • link 23年11月29日
    hdkさん (12/03 18:49)
    「>(本来1usなのに1msになって...」
  • link 23年11月29日
    すずきさん (12/03 00:35)
    「大山先生、お久しぶりです。コメントありが...」
  • link 23年11月29日
    大山恵弘さん (12/02 18:53)
    「すずきさんのX(旧Twitter)へのポ...」
  • link 20年7月12日
    すずきさん (10/19 11:17)
    「ご指摘ありがとうございます。9月の編集は...」
  • link 20年7月12日
    通り縋りさん (10/18 19:08)
    「上の記事2023年9月編集という事ですが...」
  • link 23年9月22日
    すずきさん (09/23 21:14)
    「そうなんですよ。賢いなーと思って自分でも...」
  • link 23年9月22日
    hdkさん (09/23 14:56)
    「+1だから、繰り上がる時は必ず下のほうに...」
  • link 23年9月2日
    すずきさん (09/06 18:21)
    「dアカウント自体はMNPと関係なく存在す...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20