steletoの日記 このページをアンテナに追加 RSSフィード

2017-08-30

[] 今日のGR-PEACH 02:17  今日のGR-PEACH - steletoの日記 を含むブックマーク  今日のGR-PEACH - steletoの日記 のブックマークコメント

ずっと『うーんinitarm()以降のシリアルが出ないなードライバ実装どっかバグってんのかなー』と思ってたけど、結局bus_space_map()したときに取得したhandlepを保存しておくのを忘れてたせいだった。それを直したらなんかダバダバ流れてきてデバッガに落ちた模様。

U-Boot 2015.01-00076-gc83df16e6b-dirty (Jul 06 2017 - 01:45:26)

I2C:   ready
DRAM:  10 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
                      SPI Flash Memory Map
                ------------------------------------
                         Start      Size     SPI
                u-boot:  0x00000000 0x080000 0
                   env:  0x00080000 0x040000 0
                    DT:  0x000C0000 0x040000 0
                Kernel:  0x00100000 0x050000 0
                Rootfs:  0x00600000 0x0A0000 0
Net:   sh_eth
=> bootp 192.168.0.6:netbsd.bin
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Full
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.0.4 (644 ms)
Using sh_eth device
TFTP from server 192.168.0.6; our IP address is 192.168.0.4
Filename 'netbsd.bin'.
Load address: 0x20000000
Loading: #################################################################
         #################################################################
         #################################################################
         ####################################
         2.8 MiB/s
done
Bytes transferred = 3378964 (338f14 hex)
=> go 0x20000000
## Starting application at 0x20000000 ...
  PC=0x20000024
  SP=0x208afdb0
CPSR=0x600001d3
<cortex_init>@ABC12-</cortex_init>
<mmu_init_table></mmu_init_table>
<arm_cpuinit>FG01H1IJKLM</arm_cpuinit>
jump to start()

uboot arg = 0x1, 0x208b0e5c, 0x208b0e5c, 0x20000000

NetBSD/evbarm (EVBARM_BOARDTYPE) booting ...
initarm: Configuring system, CLIDR=1110000003 CTR=0x83338003
arm32_bootmem_init: memstart=0x20000000, memsize=0x10000000, kernelstart=0x20000000
arm32_bootmem_init: kernelend=0x20356000
arm32_bootmem_init: adding 32341 free pages: [0x20356000..0x2fffffff] (VA 0x80356000)
arm32_kernel_vm_init: 1 L2 pages are needed to map 0x38a000 kernel bytes
arm32_kernel_vm_init: allocating page tables for kerneladd_pages: adding pv 0x8033964c (pa 0x20356000, va 0x80356000, 1 pages) at tail
 vmadd_pages: appending pv 0x8033a5d0 (0x20358000..0x2035bfff) to 0x20356000..0x20357fff
add_pages: appending pv 0x80339824 (0x2035c000..0x2035dfff) to 0x20356000..0x2035bfff
add_pages: appending pv 0x80339838 (0x2035e000..0x2035ffff) to 0x20356000..0x2035dfff
add_pages: appending pv 0x8033984c (0x20360000..0x20361fff) to 0x20356000..0x2035ffff
add_pages: appending pv 0x80339860 (0x20362000..0x20363fff) to 0x20356000..0x20361fff
add_pages: appending pv 0x80339874 (0x20364000..0x20365fff) to 0x20356000..0x20363fff
add_pages: appending pv 0x80339888 (0x20366000..0x20367fff) to 0x20356000..0x20365fff
add_pages: appending pv 0x8033989c (0x20368000..0x20369fff) to 0x20356000..0x20367fff
add_pages: appending pv 0x803398b0 (0x2036a000..0x2036bfff) to 0x20356000..0x20369fff
arm32_kernel_vm_init: allocating stacks
add_pages: appending pv 0x80339d44 (0x2036c000..0x2036dfff) to 0x20356000..0x2036bfff
add_pages: appending pv 0x80339d30 (0x2036e000..0x2036ffff) to 0x20356000..0x2036dfff
add_pages: appending pv 0x80339d1c (0x20370000..0x20371fff) to 0x20356000..0x2036ffff
add_pages: appending pv 0x80339d08 (0x20372000..0x20373fff) to 0x20356000..0x20371fff
add_pages: appending pv 0x80339cf4 (0x20374000..0x20375fff) to 0x20356000..0x20373fff
add_pages: appending pv 0x80339d58 (0x20376000..0x20377fff) to 0x20356000..0x20375fff
add_pages: appending pv 0x80339690 (0x20378000..0x2037bfff) to 0x20356000..0x20377fff
Creating L1 page table at 0x20358000
arm32_kernel_vm_init: adding L2 pt (VA 0x80356000, PA 0x20356000) for VA 0x80000000 (kernel)
arm32_kernel_vm_init: adding L2 pt (VA 0x8035c000, PA 0x2035c000) for VA 0xc0000000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x8035e000, PA 0x2035e000) for VA 0xc0800000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x80360000, PA 0x20360000) for VA 0xc1000000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x80362000, PA 0x20362000) for VA 0xc1800000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x80364000, PA 0x20364000) for VA 0xc2000000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x80366000, PA 0x20366000) for VA 0xc2800000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x80368000, PA 0x20368000) for VA 0xc3000000 (vm)
arm32_kernel_vm_init: adding L2 pt (VA 0x8036a000, PA 0x2036a000) for VA 0xc3800000 (vm)
Mapping kernel
arm32_kernel_vm_init: adding chunk for kernel text 0x20000000..0x20267fff (VA 0x80000000)
add_pages: adding pv 0x80339638 (pa 0x20000000, va 0x80000000, 308 pages) before pa 0x20356000
arm32_kernel_vm_init: adding chunk for kernel data/bss 0x20268000..0x20355fff (VA 0x80268000)
add_pages: adding pv 0x80339624 (pa 0x20268000, va 0x80268000, 119 pages) before pa 0x20356000
Listing Chunks
arm32_kernel_vm_init: pv 0x80339638: chunk VA 0x80000000..0x80267fff (PA 0x20000000, prot 7, cache 1)
arm32_kernel_vm_init: pv 0x80339624: chunk VA 0x80268000..0x80355fff (PA 0x20268000, prot 3, cache 1)
arm32_kernel_vm_init: pv 0x8033964c: chunk VA 0x80356000..0x8037bfff (PA 0x20356000, prot 3, cache 1)

Mapping Chunks
arm32_kernel_vm_init: mapping chunk VA 0x80000000..0x80267fff (PA 0x20000000, prot 7, cache 1)
pmap_map_chunk: pa=0x20000000 va=0x80000000 size=0x268000 resid=0x268000 prot=0x7 cache=1
SSLLLLLLPPPP
arm32_kernel_vm_init: mapping chunk VA 0x80268000..0x80355fff (PA 0x20268000, prot 3, cache 1)
pmap_map_chunk: pa=0x20268000 va=0x80268000 size=0xee000 resid=0xee000 prot=0x3 cache=1
PPPPLLLLLLLLLLLLLLPPP
arm32_kernel_vm_init: mapping last chunk VA 0x80356000..0x8037bfff (PA 0x20356000, prot 3, cache 1)
pmap_map_chunk: pa=0x20356000 va=0x80356000 size=0x26000 resid=0x26000 prot=0x3 cache=1
PPPPPLPPPPPP
devmap: 18000000 -> 1fffffff @ f7000000
pmap_map_chunk: pa=0x18000000 va=0xf7000000 size=0x8000000 resid=0x8000000 prot=0x3 cache=0
sSsSsSsSsSsSsSsS
devmap: 3fe00000 -> 3fffffff @ ff000000
pmap_map_chunk: pa=0x3fe00000 va=0xff000000 size=0x200000 resid=0x200000 prot=0x3 cache=0
SS
devmap: e8000000 -> e82fffff @ ff200000
pmap_map_chunk: pa=0xe8000000 va=0xff200000 size=0x300000 resid=0x300000 prot=0x3 cache=0
SSS
devmap: fc000000 -> fc0fffff @ ff500000
pmap_map_chunk: pa=0xfc000000 va=0xff500000 size=0x100000 resid=0x100000 prot=0x3 cache=0
S
devmap: fcf00000 -> fcffffff @ ff600000
pmap_map_chunk: pa=0xfcf00000 va=0xff600000 size=0x100000 resid=0x100000 prot=0x3 cache=0
S
devmap: fff00000 -> ffffffff @ ff700000
pmap_map_chunk: pa=0xfff00000 va=0xff700000 size=0x100000 resid=0x100000 prot=0x3 cache=0
S
devmap: f0000000 -> f00fffff @ ff800000
pmap_map_chunk: pa=0xf0000000 va=0xff800000 size=0x100000 resid=0x100000 prot=0x3 cache=0
S
                             Physical              Virtual        Num
                       Starting    Ending    Starting    Ending   Pages
               SDRAM: 0x20000000 0x2fffffff 0x80000000 0x8fffffff 32768
        text section: 0x20000000 0x20267fff 0x80000000 0x80267fff 308
        data section: 0x202c0000 0x20338f18 0x802c0000 0x80338f18 61
         bss section: 0x20338f18 0x20354fe0 0x80338f18 0x80354fe0 15
   L1 page directory: 0x20358000 0x2035bfff 0x80358000 0x8035bfff 2
   ABT stack (CPU 0): 0x2036c000 0x2036dfff 0x8036c000 0x8036dfff 1
   FIQ stack (CPU 0): 0x2036e000 0x2036ffff 0x8036e000 0x8036ffff 1
   IRQ stack (CPU 0): 0x20370000 0x20371fff 0x80370000 0x80371fff 1
   UND stack (CPU 0): 0x20372000 0x20373fff 0x80372000 0x80373fff 1
  IDLE stack (CPU 0): 0x20374000 0x20375fff 0x80374000 0x80375fff 1
           SVC stack: 0x20376000 0x20377fff 0x80376000 0x80377fff 1
      Message Buffer: 0x20378000 0x2037bfff 0x80378000 0x8037bfff 2
         Free Memory: 0x2037c000 0x2fffffff                       32322
TTBR0=0x209fc05b TTBR1=0x209fc05b TTBCR=0x1 CONTEXTIDR=0
switching to new L1 page table @0x20358000... ttb (TTBCR=0x11 TTBR0=0x2035805b TTBR1=0x2035805b) OK
nfreeblocks = 1, free_pages = 32322 (0x7e42)
bootstrap done.
vectors vbar=0x8000bf60 0x8000bf60
init subsystems: stacks vectors undefined page pmap_physload pmap kpm tlb0 locks l1pt cache(l1pt) specials pools [ Kernel symbol table missing! ]
done.
panic: pool_get: pcache: page empty
Stopped in pid 0.1 (system) at  80005a80:       bx      r14
db>

2017-07-05

[] GR-PEACHでxputc 00:54  GR-PEACHでxputc - steletoの日記 を含むブックマーク  GR-PEACHでxputc - steletoの日記 のブックマークコメント

GR-PEACHNetBSD載せらんねーかなという実験の手始めとしてブートローダのところを見ていると、どうもシリアルコンソールにデバッグ出力としてxputcというサブルーチンで行っているものがある。実態はおそらくsrc/sys/arch/arm/cortex/a9_mpsubr.SっぽいけどどうもRZ/A1Hでそのまま使えるかというとなんか微妙な気がする…ということでRZ/A1H向けのxputcを実装してみた。xputc以外はビルドを通すために用意しただけので空関数だったりと超適当。

おRZ/A1Hのシリアル出力は最大16文字分のバッファがあるので、正しくシリアル出力ができているかを確認したい場合は16文字以上の文字列を出す必要がある。それと文字化けや欠けが発生してもわかるよう、それなりの意味のある文字列が望ましい。…ということで10秒くらい考えた結果こうなった。

	.section .start,"ax",%progbits

	.global	_C_LABEL(grpeach_start)
_C_LABEL(grpeach_start):
	PRINT("hey, favstar! ban stop me premiamu! -- @toshi_a")

loop:
	b loop

と、こんなておくれプログラムでとりあえずxputcでシリアル出力ができることは確認できた。

ただこれでできたnetbsd.binをGR-PEACHに読ませようとしたときに気がついたんだけど、今のところ3MBはあるnetbsd.binをGR-PEACHのメモリに配置する方法がない。というのも、

  • シリアル(xmodem等) → なぜか600KiBほど転送した段階で固まる
  • USB → microUSB端子に刺さるものを持っていない
  • Ethernet → u-bootで対応しているようだけどコネクタを付けていない、ついでにHUBのポートも足りない
  • microSD → まさかのu-boot未対応

という状況。ちなみにxputcの確認はどうせコードは手前の領域だろうということで、xmodem転送中にフリーズしたらリセットして何食わぬ顔で実行、という手段で良かったんだけども。ぐぬぬ

2017-07-03

[] CubieBoard2サーバが起動しなくなった問題(解決しなかった) 00:08  CubieBoard2サーバが起動しなくなった問題(解決しなかった) - steletoの日記 を含むブックマーク  CubieBoard2サーバが起動しなくなった問題(解決しなかった) - steletoの日記 のブックマークコメント

はい

Welcome to minicom 2.7

OPTIONS: I18n
Compiled on Feb  9 2017, 05:05:04.
Port /dev/ttyU0

Press CTRL-A Z for help on special keys

ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24), retrying
ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24), retrying
ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24)

ということでまたサーバにアクセスできなくなったのでシリアル繋いだ結果がこれである。うーんやっぱりHDDがイカンっぽいがどうしたものか。

ところでSSDの値段見てたらWestern DigitalSanDiskがそれぞれ製品出してたけどそれ中身一緒だったりしないん?

2017-06-11

[] CubieBoard2サーバが起動しなくなった問題(解決済み) 12:02  CubieBoard2サーバが起動しなくなった問題(解決済み) - steletoの日記 を含むブックマーク  CubieBoard2サーバが起動しなくなった問題(解決済み) - steletoの日記 のブックマークコメント

ファイル置き場やproxyに使っているCubieBoard2(NetBSD/evbarm 7.1)が先週当たりから応答しない。とりあえずシリアルケーブルで母艦と繋いでみる。

wd0 at atabus0 drive 0
wd0: <Hitachi HTS545050B9A300>
wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
boot device: wd0
root on wd0a dumps on wd0b
/: replaying log to memory
root file system type: ffs
Sun Jun  4 01:45:20 JST 2017
Starting root file system check:
panic: kernel diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed: file "/home/star/work/netbsd/src/sys/uvm/uvm_vnode.c", line 355
Stopped in pid 21.1 (fsck) at   netbsd:cpu_Debugger+0x4:        bx      r14
db{1}>

おぉうなんでか知らんけどfsckでkernel panicしとる。最初はディスクが死んだかと思ったけどシングルユーザモードでなら起動できたのでSMARTを見た感じでは大丈夫…そうな気がする(これの読み方をよく知らない)。

# atactl /dev/wd0 smart status
SMART supported, SMART enabled
id value thresh crit collect reliability description                 raw
  1 100   62     yes online  positive    Raw read error rate         0
  2 100   40     yes offline positive    Throughput performance      0
  3 243   33     yes online  positive    Spin-up time                30064771072
  4 100    0     no  online  positive    Start/stop count            636
  5 100    5     yes online  positive    Reallocated sector count    0
  7 100   67     yes online  positive    Seek error rate             0
  8 100   40     yes offline positive    Seek time performance       0
  9  30    0     no  online  positive    Power-on hours count        30862
 10 100   60     yes online  positive    Spin retry count            0
 12 100    0     no  online  positive    Device power cycle count    615
191 100    0     no  online  positive    G-sense error rate          0
192 100    0     no  online  positive    Power-off retract count     77
193  37    0     no  online  positive    Load cycle count            638702
194 171    0     no  online  positive    Temperature                 32 Lifetime min/max 10/56
196 100    0     no  online  positive    Reallocated event count     0
197 100    0     no  online  positive    Current pending sector      0
198 100    0     no  offline positive    Offline uncorrectable       0
199 200    0     no  online  positive    Ultra DMA CRC error count   145240
223 100    0     no  online  positive    Load/unload retry count     0

であればfsckをかけてチェックをかけて…ってそこでkernel panicしてるのか。とりあえず試しにディスクを引っこ抜いて母艦に繋げてそちらで動かしてみる。

$ sudo fsck_ffs -fy /dev/wd3a
** /dev/rwd3a
** File system is already clean
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=11210928
CLEAR? yes

UNKNOWN FILE TYPE I=11210929
CLEAR? yes

UNKNOWN FILE TYPE I=11210930
CLEAR? yes
   :
   :

おぉ動いた。そしてエラーまみれだ orz

そしてfsckをかけ終わったディスクをCubieBoard2に戻したら無事に起動するようになったのでとりあえずそのまま動かすことに。NetBSD 8が出たころに改めてディスク診断をかけてクリーンインストールかなー。

2013-06-23

[][] 玄箱HG Update (2) 17:10  玄箱HG Update (2) - steletoの日記 を含むブックマーク  玄箱HG Update (2) - steletoの日記 のブックマークコメント

基本的に本家ドキュメント「LinkStation Installation」の通り。

シリアル出力改造は既に済ませてあるので、シリアル接続して玄箱HGの電源をON。

******* Product Information *******
---------------------------------- 
Product Name: KURO-BOX/HG(IESHIGE)
          VER: 1.00               
         Date: 2004/10/19 17:18:54
----------------------------------
Firmware check:done.              
                    
>>root=/dev/hda1
Now Loading...done.
Now Booting        
Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.17_mvl21 (root@toda_dev.melcoinc.co.jp) (gcc version 2.95.3 20010315 (release/MontaVista)) #24 2004&#254; 10&#249; 19 &#254;&#254;&#254; 17:17:03 JST
KURO-BOX (C) 2004 KUROUTO-SHIKOU.
... snip ...
hda: Hitachi HTS545050B9A300, ATA DISK drive
... snip ...
Kuroutoshikou KURO-BOX/HG (IESHIGE)

KURO-BOX-EM login:

きちんとHDDを認識できているのを確認して「root/kuroadmin」でログイン。Linuxバージョン表記の列で日付と思わしきものが化けたが知らん。(ぉ

続いて母艦からu-bootイメージを転送。

$ ftp ftp://root:kuroadmin@192.168.0.3/
Connected to 192.168.0.3.
220 KURO-BOX-EM FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
331 Password required for root.
230- Linux 2.4.17 ppc unknown
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Type set to I.
ftp> put u-boot-hg.flash.bin 
local: u-boot-hg.flash.bin remote: u-boot-hg.flash.bin
227 Entering Passive Mode (192,168,0,3,4,1)
150 Opening BINARY mode data connection for 'u-boot-hg.flash.bin'.
100% |***********************************|   170 KiB  428.62 KiB/s    00:00 ETA
226 Transfer complete.
174668 bytes sent in 00:00 (350.27 KiB/s)
ftp> bye
221 Goodbye.

どこに転送されたのかと思ってたら/rootだったので、そこに移動して/dev/fl2に(一応バックアップを取ってから)catで流し込む。

# cd /root
# ls -l
-rw-r-----    1 root     root       174668 Jun 24 02:30 u-boot-hg.flash.bin
# cat /dev/fl2 > fl2.old.bin
# cat u-boot-hg.flash.bin > /dev/fl2

書き込みが終わったらもう一度/dev/fl2を読み込んでバイナリが一致しているか比較する。

# cat /dev/fl2 > fl2.bin
# cmp -l fl2.bin u-boot-hg.flash.bin
cmp: No such file or directory

おおっとEMモードだとcmpが無いのか。しからば母艦に転送させて比較。

cmp: EOF on u-boot-hg.flash.bin: char 174669, line 862

u-boot-hg.flash.binファイルは174668バイトなのでこれでOK。

では玄箱HGを再起動。

U-Boot 1.1.4 LiSt 2.1.0 (Sep 21 2006 - 00:14:53) LinkStation HG / KuroBox HG

CPU:   MPC8245 Revision 1.4 at 262.144 MHz: 16 kB I-Cache 16 kB D-Cache
DRAM:  128 MB
FLASH:  4 MB
*** Warning - bad CRC, using default environment

        00  0b  10ec  8169  0200  ff
        00  0c  1095  0680  0101  ff
        00  0e  1033  0035  0c03  ff
        00  0e  1033  0035  0c03  ff
        00  0e  1033  00e0  0c03  ff
Net:   RTL8169#0

初期値がnetcatとかいうものらしく、ここで20秒ほど待ち状態になる。このまま放置してタイムアウトさせると次に進む。

next_cons_choice: Unexpected code: 0x33
stdin :   serial
stdout:   serial
stderr:   serial
IDE:   Bus 0: OK
  Device 0: Model: Hitachi HTS545050B9A300 Firm: PB4OC64G Ser#: 110112PBN400171E
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
Boot in 02 seconds ('s' to stop)...

ここまできたら「s」で停止させ、環境変数を変更して起動時にシリアルモードに落ちるように設定。

=> run ser          
=> setenv bootcmd
=> setenv bootdelay -1
=> saveenv 
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
Flash erase: first = 54 @ 0xfff60000
             last  = 54 @ 0xfff60000
Flash erase: Done
Erased 1 sectors        
Writing to Flash... done
Protected 1 sectors

完。