2017/07/13

[zybo]PetaLinux (7)

(2017/07/13 21:59:タイトルが6番になっていたので、7番に修正)

まず、Digilentが提供しているpetalinux-bspsの、ビルド済みを動かしてみよう。
BOOT.BINとimage.ubをSDカードにコピーするだけだ。

libphy: MACB_mii_bus: probed
mdio_bus e000b000.etherne: /amba/ethernet@e000b000/mdio has invalid PHY address
mdio_bus e000b000.etherne: scan phy mdio at address 0
mdio_bus e000b000.etherne: scan phy mdio at address 1
mdio_bus e000b000.etherne: scan phy mdio at address 2
mdio_bus e000b000.etherne: scan phy mdio at address 3
mdio_bus e000b000.etherne: scan phy mdio at address 4
mdio_bus e000b000.etherne: scan phy mdio at address 5
mdio_bus e000b000.etherne: scan phy mdio at address 6
mdio_bus e000b000.etherne: scan phy mdio at address 7
mdio_bus e000b000.etherne: scan phy mdio at address 8
mdio_bus e000b000.etherne: scan phy mdio at address 9
mdio_bus e000b000.etherne: scan phy mdio at address 10
mdio_bus e000b000.etherne: scan phy mdio at address 11
mdio_bus e000b000.etherne: scan phy mdio at address 12
mdio_bus e000b000.etherne: scan phy mdio at address 13
mdio_bus e000b000.etherne: scan phy mdio at address 14
mdio_bus e000b000.etherne: scan phy mdio at address 15
mdio_bus e000b000.etherne: scan phy mdio at address 16
mdio_bus e000b000.etherne: scan phy mdio at address 17
mdio_bus e000b000.etherne: scan phy mdio at address 18
mdio_bus e000b000.etherne: scan phy mdio at address 19
mdio_bus e000b000.etherne: scan phy mdio at address 20
mdio_bus e000b000.etherne: scan phy mdio at address 21
mdio_bus e000b000.etherne: scan phy mdio at address 22
mdio_bus e000b000.etherne: scan phy mdio at address 23
mdio_bus e000b000.etherne: scan phy mdio at address 24
mdio_bus e000b000.etherne: scan phy mdio at address 25
mdio_bus e000b000.etherne: scan phy mdio at address 26
mdio_bus e000b000.etherne: scan phy mdio at address 27
mdio_bus e000b000.etherne: scan phy mdio at address 28
mdio_bus e000b000.etherne: scan phy mdio at address 29
mdio_bus e000b000.etherne: scan phy mdio at address 30
mdio_bus e000b000.etherne: scan phy mdio at address 31
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 147 (d8:80:39:5e:8a:d6)
macb e000b000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2014 Intel Corporation.


(中略)

macb e000b000.ethernet eth0: link up (100/Full)

link upしているし、DHCP環境でIPアドレスもとれている。
pingもできた。


よし、ここから始めよう。
でも、眠たいので次回だ。


2017/07/13 22:00

QSPI、Digilent、自分の3つログがあるので、見比べてみた。

差分が簡単にとれないので、目に付いたところから調べていこう。
今回は、ここ。


QSPI
Calibrating delay loop... 1299.25 BogoMIPS (lpj=6496256)

Digilent
Calibrating delay loop... 1292.69 BogoMIPS (lpj=6463488)


Calibrating delay loop (skipped), value calculated using timer frequency.. 650.00 BogoMIPS (lpj=3250000)


私のだけログの出方が違うし、スピードも半分くらいしか出てない。
lpjというやつが半分くらいしかないためだろうか?
これまでで、一番解決しそうな手がかりだ。


まず、どういう値なのか。
有効となったCPU数と各CPUのBogoMIPS値の合計を示すメッセージ - ZDNet Japan

由来などは、Wikipediaに出てくるだろうから、それを読んでおくれ。

そして、lpj。
CPUのBogoMIPS値を計算した結果を表示するメッセージ - ZDNet Japan

lpjからBogoMIPSの値を計算しているようだ。
そして、その値の関係に違いは無い。

QSPI
1299.25 / 6496256 = 200 x 10^-6

Digilent
1292.69 / 6463488 = 200 x 10^-6


650.00 / 3250000 = 200 x 10^ -6

QSPとDigilentは199.9999...となるので、もう200にした。


それにしても、私のBogoMIPSはあまりにきれいな値すぎないか?
まさか、(skipped)って、BogoMIPSの処理をスキップして、何か設定値を使っているというなのか。


PetaLinuxでインストールされたkernelの場所はわからんかったが、init/calibrate.cのcalibrate_delay()にあるようだ。
短い関数なので、まるまる載せよう。
違うkernelなのだが、そこまで変わらんだろう。

void calibrate_delay(void)
{
	unsigned long lpj;
	static bool printed;
	int this_cpu = smp_processor_id();

	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
		lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
		if (!printed)
			pr_info("Calibrating delay loop (skipped) "
				"already calibrated this CPU");
	} else if (preset_lpj) {
		lpj = preset_lpj;
		if (!printed)
			pr_info("Calibrating delay loop (skipped) "
				"preset value.. ");
	} else if ((!printed) && lpj_fine) {
		lpj = lpj_fine;
		pr_info("Calibrating delay loop (skipped), "
			"value calculated using timer frequency.. ");
	} else if ((lpj = calibrate_delay_is_known())) {
		;
	} else if ((lpj = calibrate_delay_direct()) != 0) {
		if (!printed)
			pr_info("Calibrating delay using timer "
				"specific routine.. ");
	} else {
		if (!printed)
			pr_info("Calibrating delay loop... ");
		lpj = calibrate_delay_converge();
	}
	per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
	if (!printed)
		pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
			lpj/(500000/HZ),
			(lpj/(5000/HZ)) % 100, lpj);

	loops_per_jiffy = lpj;
	printed = true;

	calibration_delay_done();
}

今回は、3番目のルートを通ったログを見ていることになる。
よって、lpjはlpj_fineという値を参照している。

困ったことに、lpj_fineはこのファイル内に定義してあるものの、ファイル内では参照しているだけだ。
staticではないので、グローバル変数扱いか。
ちっ。


[PATCH 1/2] ARM: delay: set loops_per_jiffy when moving to timer-based loop

lpj_fine			= freq / HZ;

なので、周波数を周波数で割った値のようだ(timer->freq/HZ、というソースもあった)。


ここから一気に押し進めたいところだったが、ログの出方がそれぞれ違うので、簡単には追えないのだ。
眠たいので、今回はここまで。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。