::log.2014
[ TOP | Recently ]
Nitrogen6MAX / CuBox-i1にシリアルをつける / NetBSD/evbarm NITROGEN6X - i.MX6 processor / about KERNEL_BASE_* on evbarm / cvsの闇
2014-12-22 Nitrogen6MAX
ひと月前に自分で自分に買ったクリスマスプレゼントキタ━━━━━━(゚∀゚)━━━━━━ !!
U-Boot 2014.07-00136-gf870252 (Sep 22 2014 - 09:15:50)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Nitrogen6_max
I2C: ready
DRAM: 3.8 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
No panel detected: default to HDMI
Display: HDMI (1024x768)
In: serial
Out: serial
Err: serial
Net: using phy at 6
FEC [PRIME], usb_ether
Hit any key to stop autoboot: 0
U-Boot > ?
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
bmode - mmc0|mmc1|normal|usb|sata|escpi1:0|escpi1:1|escpi1:2|escpi1:3|esdhc1|esdhc2|esdhc3|esdhc4 [noreset]
bmp - manipulate BMP image data
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
bootz - boot Linux zImage image from memory
clocks - display clocks
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dcache - enable or disable data cache
dhcp - boot image via network using DHCP/TFTP protocol
echo - echo args to console
editenv - edit environment variable
env - environment handling commands
erase - erase FLASH memory
exit - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls - list files in a directory (default /)
false - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
fdt - flattened device tree utility commands
flinfo - print FLASH memory information
fuse - Fuse sub-system
go - start application at address 'addr'
gpio - query and control gpio pins
hdmidet - detect HDMI monitor
help - print command description/usage
i2c - I2C sub-system
icache - enable or disable instruction cache
iminfo - print header information for application image
imxtract- extract a part of a multi-image
itest - return true/false on integer compare
kbd - Tests for keypresses, sets 'keybd' environment variable
load - load binary file from a filesystem
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loadx - load binary file over serial line (xmodem mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
ls - list files in a directory (default /)
md - memory display
mdio - MDIO utility commands
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mmc - MMC sub system
mmcinfo - display MMC info
mtest - simple RAM read/write test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
reset - Perform RESET of the CPU
run - run commands in an environment variable
sata - SATA sub system
saveenv - save environment variables to persistent storage
setenv - set environment variables
setexpr - set environment variable as the result of eval expression
sf - SPI flash sub-system
showvar - print local hushshell variables
sleep - delay execution for some time
source - run script from memory
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
time - run commands and summarize execution time
true - do nothing, successfully
ums - Use the UMS [User Mass Storage]
usb - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
U-Boot > ver
U-Boot 2014.07-00136-gf870252 (Sep 22 2014 - 09:15:50)
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
GNU ld (GNU Binutils for Ubuntu) 2.24
U-Boot > base
Base Address: 0x00000000
U-Boot > bdinfo
arch_number = 0x00000EC2
boot_params = 0x10000100
DRAM bank = 0x00000000
-> start = 0x10000000
-> size = 0xF0000000
eth0name = FEC
ethaddr = 00:19:b8:01:97:1a
eth1name = usb_ether
eth1addr = (not set)
current eth = FEC
ip_addr = <NULL>
baudrate = 115200 bps
TLB addr = 0xFFFF0000
relocaddr = 0xFFF52000
reloc off = 0xE8752000
irq_sp = 0xFF34FEC0
sp start = 0xFF34FEB0
FB base = 0xFF357300
U-Boot > clocks
PLL_SYS 792 MHz
PLL_BUS 528 MHz
PLL_OTG 480 MHz
PLL_NET 50 MHz
IPG 66000 kHz
UART 80000 kHz
CSPI 60000 kHz
AHB 132000 kHz
AXI 264000 kHz
DDR 528000 kHz
USDHC1 198000 kHz
USDHC2 198000 kHz
USDHC3 198000 kHz
USDHC4 198000 kHz
EMI SLOW 132000 kHz
IPG PERCLK 66000 kHz
U-Boot > coninfo
List of available devices:
vga 80000002 S.O
serial 80000003 SIO stdin stdout stderr
nulldev 80000003 SIO
mxc_serial 00000003 .IO
nc 80000003 SIO
U-Boot > dcache
Data (writethrough) Cache is ON
U-Boot > dcache
Data (writethrough) Cache is ON
U-Boot > printenv
baudrate=115200
board=nitrogen6_max
bootcmd=for dtype in ${bootdevs}; do if itest.s "xusb" == "x${dtype}" ; then usb start ;fi; for disk in 0 1 ; do ${dtype} dev ${disk} ;for fs in fat ext2 ; do ${fs}load ${dtype} ${disk}:1 10008000 /6x_bootscript&& source 10008000 ; done ; done ; done; setenv stdout serial,vga ; echo ; echo 6x_bootscript not found ; echo ; echo serial console at 115200, 8N1 ; echo ; echo details at http://boundarydevices.com/6q_bootscript ; setenv stdin serial,usbkbd
bootdelay=1
bootdevs=sata mmc usb
clearenv=if sf probe || sf probe || sf probe 1 ; then sf erase 0xc0000 0x2000 && echo restored environment to factory default ; fi
console=ttymxc1
cpu=6Q
ethact=FEC
ethaddr=00:19:b8:01:97:1a
ethprime=FEC
fdt_addr=0x11000000
fdt_high=0xffffffff
initrd_high=0xffffffff
loadaddr=0x12000000
loadsplash=if sf probe ; then sf read ${splashimage} c2000 ${splashsize} ; fi
stdin=serial,usbkbd
stdout=serial,vga
upgradeu=for dtype in ${bootdevs}; do for disk in 0 1 ; do ${dtype} dev ${disk} ;for fs in fat ext2 ; do ${fs}load ${dtype} ${disk}:1 10008000 /6x_upgrade && source 10008000 ; done ; done ; done
usbnet_devaddr=00:19:b8:00:00:02
usbnet_hostaddr=00:19:b8:00:00:01
usbrecover=setenv ethact usb_ether; setenv ipaddr 10.0.0.2; setenv netmask 255.255.255.0; setenv serverip 10.0.0.1; setenv bootargs console=ttymxc1,115200; tftpboot 10800000 10.0.0.1:uImage-${board}-recovery&& tftpboot 12800000 10.0.0.1:uramdisk-${board}-recovery.img && bootm 10800000 12800000
wlmac=00:19:B8:01:97:1b
Environment size: 1556/8188 bytes
U-Boot >
2014-09-30 CuBox-i1にシリアルをつける
netbsd/imx6のデバッグのためCuBox-i1を買った。テスト用なので一番安いやつ。
EtherのPHYが10/100でNITROGEN6Xと違うのでRMIIのデバッグになるかなと思って買ったのだが
consoleのUARTアドレスを変えてahcisataをコメントアウトしただけで動いてしまったので
あんまりデバッグにならず。
のは置いといて、CuBox-iはCuBoX-i1,i2,i2eX,i2ultra,i4proなど
色々ラインナップがあります。
ただしシリアルコンソール(中にUSB変換が入っていてmicro USBポートからUSB serialが見える)
が取れるのは一部の機種のようです。
一番安いモデルのCuBox-i1には当然シリアル/USB変換は付いてなかったのですが
「どーせ分解したらUARTのピンが出てるんでしょ」と思って買いました。
で開けたんですが、見当たりませんでした。ガーン。
落ち着いてCuBox-iのwikiを見たら、シリアルまわりの回路図があり、
そこにUARTのTX/RXがTP1、TP2という情報が!
基板上の位置はこのへん
というわけで、基板のTP1/TP2に秋月で買ったFT232RLをつけて無事UARTがとれるようになりました。
自分用メモ http://www.solid-run.com/wiki/U-Boot dd if=SPL of=/dev/sd0d bs=1k seek=1 dd if=u-boot.img of=/dev/sd0d bs=1k seek=42
2014-09-20 NetBSD/evbarm NITROGEN6X - i.MX6 processor
というわけで手元でちまちま作業してたのですが、MULTIPROCESSORで安定してbootするまでできました。
MULTIPROCESSORでbootした後はよく落ちます(これはsys/arch/armのせいで移植自体に問題はない…はず)
single processorなら問題ない感じ。
github
あたりは普通に使えると思います。もうちょっとcleanupしてそのうち本家にcommitします。
MULTIPROCESSORでbootした後はよく落ちます(これはsys/arch/armのせいで移植自体に問題はない…はず)
single processorなら問題ない感じ。
github
- UART
- Ethernet
- SATA
- USB
- GPIO
あたりは普通に使えると思います。もうちょっとcleanupしてそのうち本家にcommitします。
2014-09-20 about KERNEL_BASE_* on evbarm
evbarmの移植してるとこんがらがってくるのが KERNEL_BASE_PHYS、KERNEL_BASE_VIRT、KERNEL_BASE_EXT です。
KERNEL_BASE_PHYS カーネルの物理開始アドレス
KERNEL_BASE_VIRT カーネルの論理開始アドレス
KERNEL_BASE_EXT カーネルが使用可能な論理開始アドレス
です。
例えば、とあるボードは物理実装メモリが512Mbyte。
メモリマップは以下のようになっている場合を考えます。
uboot等のROMモニタが0x10000000にロードされ動作すると、ユーザプログラム
(この場合カーネル)のロードアドレスは(ubootの都合により)0x10080000等の
半端なアドレスとなります。そのため、netbsdのカーネルは0x10080000にロード
され、0x10080000から実行されることになります。
この場合、
とします。
KERNEL_BASE_VIRT は、カーネルの論理アドレスなので、netbsd側でつじつまが
あっていれば他のアドレスの場合もありえます(※)
「あれ、kernel が 0x10800000 = 0x80800000 にロードされるならば、メモリが
実装されているはずの 0x10000000〜0x10800000 の領域は無駄になるんじゃないの?」
と思った人はなかなかスルドイです。
この領域も当然もったいないので、実は当然ちゃんと使われます。
そのへんは arm32_bootmem_init() がうまくやってくれて、
arm32_bootmem_init() に、実メモリ実装範囲 0x10000000〜0x30000000、および
kernelの開始番地 0x10800000 を渡すと、実メモリの先頭からkernel開始番地の
空き領域 0x10000000〜0x10800000 をフリーページとして登録してくれて、
malloc(9)等で使えるようになります。VERBOSE_INIT_ARM を付けてコンパイルすると
起動時にそのへんの情報が表示されます。
さて、(※) で指摘した、kernelの論理アドレスを0x80000000ではなく他のアドレスに
したい場合はKERNEL_BASE_EXT を定義します。
例えば KERNEL_BASE_EXT = 0xC0000000 にすると、netbsd の userland プログラムの
論理アドレスは 0x00000000〜、kernel の開始アドレスが 0xC0000000〜 になります。
この場合、netbsd kernelで使える論理メモリ領域は
となり、この領域がkernelのtext、stackやMMU用のテーブル、malloc(9)、bus_space_map、
pool allocator等で使われます。
evbarmの場合、KERNEL_BASE は sys/arch/evbarm/include/vmparam.h でデフォルトでは
0x80000000 に定義されています。上記のようにこれを 0xC0000000 に変えたい場合は、
#define KERNEL_BASE_EXT 0xC0000000 すると、
のように定義されなおすわけです。
KERNEL_BASE_PHYS カーネルの物理開始アドレス
KERNEL_BASE_VIRT カーネルの論理開始アドレス
KERNEL_BASE_EXT カーネルが使用可能な論理開始アドレス
です。
例えば、とあるボードは物理実装メモリが512Mbyte。
メモリマップは以下のようになっている場合を考えます。
0x00000000 +----------------+ | I/O、ROM等 | | | 0x10000000 +----------------+ | メインメモリ | | 512Mbyte | | | | | 0x30000000 +----------------+ | | | 未使用 | | | 〜〜〜〜〜〜〜〜〜 〜〜〜〜〜〜〜〜〜 | | | | 0xA0000000 +----------------+ | I/O、ROM等 | | | 0xFFFFFFFF +----------------+
uboot等のROMモニタが0x10000000にロードされ動作すると、ユーザプログラム
(この場合カーネル)のロードアドレスは(ubootの都合により)0x10080000等の
半端なアドレスとなります。そのため、netbsdのカーネルは0x10080000にロード
され、0x10080000から実行されることになります。
この場合、
KERNEL_BASE_PHYS =0x10800000 KERNEL_BASE_VIRT =0x80800000 KERNEL_BASE =0x80000000
とします。
KERNEL_BASE_VIRT は、カーネルの論理アドレスなので、netbsd側でつじつまが
あっていれば他のアドレスの場合もありえます(※)
「あれ、kernel が 0x10800000 = 0x80800000 にロードされるならば、メモリが
実装されているはずの 0x10000000〜0x10800000 の領域は無駄になるんじゃないの?」
と思った人はなかなかスルドイです。
この領域も当然もったいないので、実は当然ちゃんと使われます。
そのへんは arm32_bootmem_init() がうまくやってくれて、
arm32_bootmem_init() に、実メモリ実装範囲 0x10000000〜0x30000000、および
kernelの開始番地 0x10800000 を渡すと、実メモリの先頭からkernel開始番地の
空き領域 0x10000000〜0x10800000 をフリーページとして登録してくれて、
malloc(9)等で使えるようになります。VERBOSE_INIT_ARM を付けてコンパイルすると
起動時にそのへんの情報が表示されます。
NetBSD/evbarm (nitrogen6) booting ... initarm: Configuring system (4 cpus, hatched 0xe), CLIDR=1110000003 CTR=0x83338003 arm32_bootmem_init: memstart=0x10000000, memsize=0x40000000, kernelstart=0x10800000 arm32_bootmem_init: kernelend=0x10e50000 arm32_bootmem_init: adding 129240 free pages: [0x10e50000..0x4fffffff] (VA 0x80e50000) arm32_bootmem_init: adding 1024 free pages: [0x10000000..0x107fffff] (VA 0x80000000) arm32_kernel_vm_init: 0 L2 pages are needed to map 0x6a0000 kernel bytes
さて、(※) で指摘した、kernelの論理アドレスを0x80000000ではなく他のアドレスに
したい場合はKERNEL_BASE_EXT を定義します。
例えば KERNEL_BASE_EXT = 0xC0000000 にすると、netbsd の userland プログラムの
論理アドレスは 0x00000000〜、kernel の開始アドレスが 0xC0000000〜 になります。
この場合、netbsd kernelで使える論理メモリ領域は
0xC0000000〜0xFFFFFFFFの0x40000000=1Gbyte
となり、この領域がkernelのtext、stackやMMU用のテーブル、malloc(9)、bus_space_map、
pool allocator等で使われます。
evbarmの場合、KERNEL_BASE は sys/arch/evbarm/include/vmparam.h でデフォルトでは
0x80000000 に定義されています。上記のようにこれを 0xC0000000 に変えたい場合は、
#define KERNEL_BASE_EXT 0xC0000000 すると、
=== sys/arch/evbarm/include/vmparam.h === /* * The line between user space and kernel space * Mappings >= KERNEL_BASE are constant across all processes */ #ifdef KERNEL_BASE_EXT #define KERNEL_BASE KERNEL_BASE_EXT #else #define KERNEL_BASE 0x80000000 #endif
のように定義されなおすわけです。
2014-02-20 cvsの闇
T#は時間。T1<T2<T3<T4<T5。
CASE1
T1 cvs import 1.1 1.1.1.1 T2 cvs import 1.1.1.2 T3 cvs import 1.1.1.3
だった場合、maintrunk で cvs update -DT3 とすると、1.1.1.3 が checkout される。(普通)
CASE2
T1 cvs import 1.1 1.1.1.1 T2 cvs import 1.1.1.2 T3 cvs commit 1.2 T4 cvs import 1.1.1.3
だった場合、cvs update -DT4 とすると、1.2 が checkout される。(いわゆるimport branchに対するmaintrunkの上書き)
さて、CASE1と似ているが、1.1を最初にcommitしてあった状態からimportした場合がCASE3。
CASE3
T1 cvs commit 1.1 T2 cvs import 1.1.1.1 T3 cvs import 1.1.1.2 T4 cvs import 1.1.1.3
この場合は、cvs update -DT4 とすると、1.1 が checkout される。
CASE1とCASE3は1.1と1.1.1.1のタイムスタンプしか違わなくて、実際これを見ている様子。
(rcsfileのtimestampを直接書換えたらCASE1になった)
さて、それではCASE3の状態から cvs admin -o 1.1.1.1 するとどうなるでしょう…
CASE4
T1 cvs commit 1.1 T3 cvs import 1.1.1.2 T4 cvs import 1.1.1.3
ここでcvs update -DTT4すると、1.1ではなく1.1.1.3 がcheckoutされた…。
cvsよくわからないです><
ということを調べながらcvs2gitツールを作っている今日この頃でした。
EOF