::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