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>

2016-04-21

CubieBoardにOwnCloudを入れてみた 00:44  CubieBoardにOwnCloudを入れてみた - steletoの日記 を含むブックマーク  CubieBoardにOwnCloudを入れてみた - steletoの日記 のブックマークコメント

CubieBoard2が暇しているのでファイル置き場として使えないかなーとNetBSD + nginx + php-fpm という構成でOwnCloudをインストールしてみた。ちなみにOwnCloudはpkgsrcのwww/php-owncloudに登録されてあったのでmake pacakge-installで/usr/pkg/share/owncloudに展開してくれる。ありがたやありがたや。

んでとりあえず動かしてみた感じ。

  • なぜか「コード整合性の確認で問題が発生しました」という帯が表示されてる。まぁ動作は問題なさそうなので後回し。
  • ページの切り替えがもっさりぎみ。ただし既知の遅くなる要因が複数あるのでそれのせいかも。
  • アプリ」→「実験的なアプリケーション」にある『Calendar』を有効にすると死ぬ(どのURLでも白画面しかでない)
Error: Access to undeclared static property: Sabre\\VObject\\Property::$classMap at \
/usr\/pkg\/share\/owncloud\/apps\/calendar\/appinfo\/app.php#37
    • 元に戻すにはDBに接続して "oc_appconfig" から "calender|enabled|yes”を消す
    • ちなみにCalenderは「Productivity」にもある(しかも承認済み)。が、名前が衝突しているとか何だかで入れられない
      • pkgsrcのMakefileを見るとcalenderとcontactsを自前で展開しているような気がするがそれと衝突してる?
  • ノートアプリは日本語は問題ないけど表が書けない。

んでCubieBoard2はこれまた暇している64GB SSDを繋いであったんだけど、古いデータのバックアップとか集めていたらどうも64GBでは収まりそうにないことのが判明。そのうち別の容量の大きいHDDにでも換装する予定。

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

完。

2012-12-24

[] Nano-X 01:39  Nano-X - steletoの日記 を含むブックマーク  Nano-X - steletoの日記 のブックマークコメント

NetBSD/zaurusでのXはやっぱり重い。いや正確にはgtk+2が重い。どれくらい重いかっていうとuim-pref-gtkを起動させるのに15分くらいかかる。一方fltk1.3なdillo3はそこそこ許容範囲の速度で動く。恐るべしfltk。

なんとなく直接の原因はメモリ不足なのかなーという気はするが、増設という手が使えないのでいくつか案を出してみる。

KDriveを使う
Angstromではこれが使われていたけどビルド方法がよーわからん
compcache(ramzswap)的なモノ
http://wiki.netbsd.org/projects/project/compressed-cache で募集中?
nano-X
http://www.nano-x.org/ X非互換なのが最大の問題、ただSDLやfltkは動く(らしい)

nano-XはX11向けドライバがあるようなので「んじゃあ多少手直しする程度で動くかなー」と軽い感じでNetBSD/amd64のX上に乗せてみた。

f:id:steleto:20121225013339p:image

ちなみに当初の予想に反して''全然簡単じゃなかった''。まだいくつかの付属アプリは起動できないし、そもそも90度回転している理由が不明。

あと途中で気付いたけどnano-XってXIM的な日本語入力できる枠組みってあるのかという問題が。

2011-11-07

[][] w100ドライバへの道のりは長そう 03:28  w100ドライバへの道のりは長そう - steletoの日記 を含むブックマーク  w100ドライバへの道のりは長そう - steletoの日記 のブックマークコメント

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.99.55 (C700) #4: Tue Nov  8 03:05:25 JST 2011
        star@nano.localnet:/home/star/workspace/netbsd-c7x0/obj/sys/arch/zaurus/0
total memory = 65536 KB
avail memory = 56232 KB
mainbus0 (root)        
cpu0 at mainbus0: PXA250 step B-2 (XScale core)
cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
cpu0: 32KB/32B 32-way Instruction cache                              
cpu0: 32KB/32B 32-way write-back-locking Data cache
pxaip0 at mainbus0: Onchip Peripheral Bus          
pxaip0: CPU clock = 398.093 MHz          
pxaip0: kernel is configured for PXA250, cpu type is PXA250
pxaintc0 at pxaip0 addr 0x40d00000-0x40d0001f: Interrupt Controller
pxagpio0 at pxaip0 addr 0x40e00000-0x40e0006f: GPIO Controller     
com0 at pxaip0 addr 0x40100000-0x4010001f intr 22: ns16550a, working fifo
com0: console                                                            
com1 at pxaip0 addr 0x40200000-0x4020001f intr 21: ns16550a, working fifo
com2 at pxaip0 addr 0x40700000-0x4070001f intr 20: ns16550a, working fifo
saost0 at pxaip0 addr 0x40a00000-0x40a0001f                              
saost0: SA-11x0 OS Timer                   
pxadmac0 at pxaip0 addr 0x40000000-0x400002ff intr 25: DMA Controller
pxapcic0 at pxaip0: 1 slot                                           
pcmcia0 at pxapcic0       
pxartc0 at pxaip0 addr 0x40900000-0x4090000f: Real-time Clock
pxamci0 at pxaip0 addr 0x41100000-0x41100047: MMC/SD Controller
sdmmc0 at pxamci0                                              
scoop0 at pxaip0: PCMCIA/GPIO controller
zssp0 at pxaip0                         
c700lcd0 at pxaip0: w100 LCD controller
Stopped in pid 0.1 (system) at  netbsd:__divsi3+0xe457c:        swinv   0x00ffffff
db> 

ようやくc700lcdとして認識…して直後に落ちる。しかもシリアルが断線しているのかこちらから一切の入力を受けつけてくれず。むぅ ('・ω・`)

あとここに書いてから気付いたがメモリ64MiBと誤認しとるな。(C700は32MiB)

nonakapnonakap 2011/11/09 13:13 C700はCPU_ID_PXA250AじゃなくてCPU_ID_PXA250Bなんですね。sys/arch/zaurus/zaurus/machdep.c:initarm()でC700判定を行っているので比較する値をCPU_ID_PXA250Bに変更すれば32MBで認識されると思います。

steletosteleto 2011/11/11 01:49 ご指摘ありがとうございます。おかげさまで無事32MBに認識できました。
ちなみに去年の時点では別のロジックでPXA250判定していたのですが、マージの際に今回のロジックに気付かずつっこんだ上、さらにマージも失敗していて何の役にもたたない無意味なコードと化しておりました… orz