위의 BOOTP 특성에서 알아봤듯이, BOOTP에서 정보를 교환한다는 것은 클라이언트가 보낸 요청과 서버가 보내는 답장 쌍을 이루는 것이다.
BOOTP도 일반적인 다른 '요청 / 응답 프로토콜'들과 마찬가지로 요청 및 응답에 사용되는 공통된 메시지 형식을 정의해서 사용하고 있다.
구현하기 나름이겠지만, 일반적으로 클라이언트는 요청메시지의 크기만큼의 메모리 공간을 모두 0으로 초기화 하는 것 부터 시작한다.
그런 다음 이전 항목에서 보았던 것처럼 각각의 메시지 필드를 채운 다음 요청을 서버로 보낸다.
사실 역시 구현하기 나름이겠지만, 일반적으로 서버측은 메세지를 처음부터 다시 작성하지 않고, 클라이언트로 부터 받은 요청을 메모리에 복사하고 특정 필드를 변경하여 응답을 작성한다.
BOOTP 메시지는 상당한 수의 필드를 포함하므로 메시지 형식이 상당히 크다.
UDP 데이터그램 내부의 BOOTP 메세지를 간단히 살펴보자.
IP패킷에 의해 캡슐화 된 UDP데이터그램이 있고,
UDP 데이터그램에 의해 캡슐화 된 BOOTP Message가 있다.
300 바이트, BOOTP Message의 전체 형식은 천천히 살펴보자.
아래 그림과 같다.
Field Name
Size(bytes)
Description
Op
1
Operation Code: 메시지의 타입을 지정함. 1은 요청, 2는 응답
HType
1
Hardware Type: 로컬 네트워크에서 사용하는 하드웨어 유형을 지정한다. ARP 메시지의 HRD필드와 동등한 방식으로 사용된다. 몇가지 공통된 값은 아래와 같다.
1 : Ethernet(10MB)
6 : IEEE 802 Networks
7 : ARCNET
15 : Frame Relay
16 : Asynchronous Transfer Mode(ATM)
17 : HDLC
18 : Fibre Channel
19 : Asynchronous Transfer Mode(ATM)
20 : Serial Line
HLen
1
Hardware Address Length: 이 메시지 내에서 하드웨어 주소의 길이를 지정함. 이더넷 혹은, IEEE 802 MAC 주소를 사용하는 다른 네트워크에서, 이 값은 6임.
이것은 ARP 필드 형식에서 비슷한 이름 (HLN)을 가진 필드와 동일함.
Hops
1
요청을 전달하기 전에 클라이언트에 의해 0으로 설정되고, BOOTP relay agent가 BOOTP 메시지를 포워딩 제어하는데 사용함
XID
4
Transaction Identifier: 클라이언트가 생성한 32비트 식별 값. BOOTP서버에서 받은 응답과 요청을 매칭시키기 위해 사용함.
Secs
2
Seconds: RFC 951에 의하면, 클라이언트는 이 필드에 “클라이언트가 부트를 시도한 시점부터 경과된 초단위 시간 값＂을 넣는다. 이것은 BOOTP 서버에 정보를 제공함으로써, 어느것부터 응답해야 할지를 결정하는데 도움을 준다.
불행히도 이 정의는 다소 모호했기에, 전원이 켜진 직후부터의 시간값의 양인지 혹은 첫번째 BOOTREQUEST 메시지가 보내진 이후부터를 의미하는지 명확하지 않았다. 게다가 몇몇 장치는 이 필드를 잘못 구현하기까지 했다. 결론적으로 이 필드는 항상 사용되는 것이 아니다.
Flags
2
Flags: 원래 BOOTP 표준(RFC 951)에서는, 이 필드는 2바이트의 공백이었다.
RFC1542에서는 하나의 flag를 포함하는 ‘flags’ 필드로 변경되었다.
CIAddr
4
Client IP Address: 클라이언트가 계속 사용하려는 현재 IP 주소를 가지고 있으면, 이 필드에 그 원하는 IP 주소를 넣는다. 이 필드를 채우면 클라이언트는이 주소로 전송 된 유니 캐스트 IP 데이터 그램에 응답하기 위해 커밋합니다. 그렇지 않으면 이 필드를 모두 0으로 설정하여 서버에 주소 할당을 원한다는 것을 알려준다.
YIAddr
4
“Your” IP Address: 서버가 클라이언트에 지정하는 IP 주소. 이는 클라이언트가 현재 사용하는 IP 주소와 다를 수 있다.
SIAddr
4
Server IP Address: BOOTREPLY 메시지를 보내는 BOOTP 서버의 IP주소
GIAddr
4
Gateway IP Address: 이 필드는 BOOTP 릴레이 에이전트가 BOOTP 요청의 통신을 용이하게 하고 다른 서브넷이나 네트워크에있는 클라이언트와 서버간에 회신 할 때 BOOTP 메시지를 라우팅하는 데 사용된다. 이름을 이해하려면 "router"에 대한 이전 TCP / IP 용어는 "gateway"입니다. BOOTP 릴레이 에이전트는 일반적으로 라우터이다.
이 필드는 클라이언트가 0으로 설정하고 BOOTREPLY를 처리 할 때 클라이언트가 무시해야 한다. 이것은 특히 일반적인 IP 라우팅 용도로 사용될 기본 라우터 주소의 주소를 클라이언트에 제공하는 서버를 나타내지는 않는다.
CHAddr
16
Client Hardware Address: BOOTREPLY를 보내는 클라이언트의 L2 계층 하드웨어 주소. 장치의 할당 된 IP 주소를 검색하고 응답 메시지를 전달하는 데 사용된다.
SName
64
Server Name: BOOTREPLY를 보내는 서버는 이 필드에 서버이름을 지정하거나 지정하지 않을 수 있다. 이것은 간단한 텍스트로 "nickname"와 같은 게 될 수도 있고, 아니면 완전한 DNS 도메인 이름 (예 : ＂myserver.organization.org＂) 이 될 수도 있다.
클라이언트는 요청을 만들때, 이 필드값을 지정할 수 있다. 만약 지정한다면, 그것은 이 이름을 가진 BOOTP서버로부터만 응답을 원한다는 의미이다. 이것은 클라이언트가 한 서버에만 저장된 특정 부트 파일에 액세스 할 수 있도록하기 위해 수행 될 수 있다.
File
128
Boot Filename: 부트스트랩 과정을 완료하기 위해 클라이언트가 다운로드 받을 수 있는 부트 파일의 전체 디렉토리 경로와 파일이름을 포함하는 필드. 클라이언트는 여기에 텍스트로 설명을 입력하여 특정 유형의 파일을 요청할 수 있다. 혹은 이 필드를 공백으로 남겨두고, 서버가 기본 파일의 이름을 제공하게 할 수 있다.
Vend
64
Vendor-Specific Area: 원래는 제조사(공급업체)로 하여금 BOOTP를 다른 유형의 하드웨어 요구에 맞게 수정할 수 있도록 허용하는 필드다. 이 필드는 지금은 제조사 독립적인 설정 정보를 보관하는데에도 사용한다.
앞서 언급했지만, BOOTP 서버/클라이언트의 양측의 요청 및 응답 메세지는 UDP 메시지로 캡슐화되어 전송된다.
BOOTP 표준(rfc951)에서는 UDP checksum 사용을 'optional'로 정의하고 있다.
UDP checksum을 사용하면 데이터 무결성 오류를 방지 할 수 있으므로 권장된다.
그러나 이 기능은 종종 아주간단히 구현된 클라이언트 측에서는 받아 들일 수없는 처리 요구를 유발할 수도 있기때문에, checksum을 합법적으로 생략할 수도 있다.
참고로, 간결함을 위해, BOOTP는 메세지 패킷이 분할(fragmented) 되지 않는다고 가정한다.
이를통해 BOOTP 클라이언트는 분할된 메세지를 모으고, 시퀀스 넘버순서대로 다시 합치는 복잡한 과정을 피할수 있다.
패킷의 분할을 지원하지 않으면, 각 레이어 별로 길이가 초과되는 경우에 어떻게 처리되어야 하는가 고민이 생길수도 있다.
하지만, BOOTP메세지는 모든 TCP/IP연결에서 요구되는 최소 MTU보다도 작은, 겨우 300바이트 길이이기 때문에, 일반적으로 이는 문제가 되지 않는다.
판다보드에서 리눅스를 부팅한 후, ifconfig로 확인해보면 'lo' 라고 표시되는 loopback interface (127.0.0.1) 만 bring up되고, eth0(ethernet)과 wlan0(Wi-Fi interface)는 자동으로 bring up되지 않는다.
'ifconfig up wlan0', 'ifconfig up eth0' 을 사용해서 커맨드라인에서 수동으로 bring up 을 해보면, 정상적으로 bring up 되는 것을 확인했다.
부팅시퀀스에서 bring up 되도록 하는 방법이 있을 텐데 비활성화 되어 있는 것 같다.
TI 의 ARM Cortex A9 기반의 임베디드 보드인 PandaBoard ES에는 내장된 별도의 저장공간이 없다.
대신에 sd card슬롯을 제공하고, sd카드의 boot partition을 통해 부팅을 하게된다.
아무래도 trial(시험용) 보드 성격이 강해서 그런 것이리라..
우선 판다보드 부팅에 사용할 sd카드를 준비하는 작업이 필요하다.
다음 순서로 진행할 것이다.
1. SD카드 파티션 분할 및 각 파티션 포맷
2. U-Boot 소스코드 다운로드 및 빌드
3. Linux Kernel 소스코드 다운로드 및 빌드
4. Ubuntu의 Root File System 확보 및 SD카드에 복사
5. Wi-Fi driver firmware 확보 및 SD카드에 복사
6. /etc/fstab를 통해 각 파티션을 자동마운트 되도록 수정
파티션 구성
아래와 같이 4개의 파티션으로 구성했다.
16GB SD카드를 우분투로 동작중인 host pc에 꽂으니 /dev/sdc 로 인식되었다.
이를 sdc1 ~ sdc4 까지 4개의 파티션으로 나누었다.
이 부분은 각자의 환경에 따라 다르게 인식될 수 있다.
즉, /dev/sdb가 될 수도 있고... /dev/sdd가 될 수도 있으며.. /dev/mmcblk0 이런식이 될 수도 있다.
Command (m for help): p Disk /dev/sdc: 14.7 GiB, 15719727104 bytes, 30702592 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6114984e
Device Boot Start End Sectors Size Id Type /dev/sdc1 * 2048 2099199 2097152 1G c W95 FAT32 (LBA) /dev/sdc2 2099200 23070719 20971520 10G 83 Linux /dev/sdc3 23070720 27265023 4194304 2G 83 Linux /dev/sdc4 27265024 30702591 3437568 1.7G 82 Linux swap / Solaris
sdc1는 부팅 파티션으로, u-boot.img와 MLO를 넣고, boot flag를 true로 했다.
filesystem type은 FAT32 (LBA)로 하였다.
sdc2는 리눅스를 위한 root 파티션으로, 10GB를 할당했고, filesystem type은 ext4로 했다.
sdc3은 리눅스의 /var 디렉토리를 위한 파티션으로, 2GB를 할당했다. filesystem type은 ext4로 했다.
sdc4는 리눅스의 swap 파티션으로 남은 공간 전체를 할당했다.
파티션 포맷 (Format Partition)
나누어둔 파티션을 실제로 사용하기 위해서는 각각의 파티션을 포맷해야 한다.
jeon@ubuntu:~$ sudo mkfs.vfat -F 32 -n boot /dev/sdc1 [sudo] password for jeon: mkfs.fat 3.0.28 (2015-05-16) mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
tar xf ubuntu-16.04.1-minimal-armhf-2016-09-17.tar.xz
참고로 이 ubuntu의 계정은 'ubuntu'이고 암호는 'temppwd' 이다.
root file 복사하기
sudo mount /dev/sdc2 /media/rootfs sudo tar xfvp ./*-*-*-armhf-*/armhf-rootfs-*.tar -C /media/rootfs/
파일시스템 테이블 (/etc/fstab)
이 작업을 해두어야, 부팅시 자동으로 마운트가 된다.
/media/rootfs//etc/fstab 는 처음에 아무런 내용이 없이 주석이 달린 1줄만 있다.
나는 4개의 파티션으로 나누었으므로 아래와 같이 mount point및 mount option등을 지정해 주었다.
만약 fstab에 대해 익숙하지 않다면, 이에 대해 알아볼 것은 권한다.
내용은 많지 않으나, 여기서는 자세히 다루지 않겠다.
jeon@ubuntu:/media/jeon/rootfs$ cat etc/fstab # UNCONFIGURED FSTAB FOR BASE SYSTEM /dev/mmcblk0p1 /boot vfat errors=remount-ro 0 0 /dev/mmcblk0p2 / ext4 errors=remount-ro 0 1 /dev/mmcblk0p3 /var ext4 auto 0 0 /dev/mmcblk0p4 none swap sw 0 0
간략히 알아보면, fstab은 총 6개의 부분으로 나누어져 있다.
첫번째는 File System Device Name, 두번째는 Mount Point, 세번째는 FileSystem Type, 네번째는 Mount Option, 다섯번째와 여섯번째 숫자의 의미는 각각 Dump할지 말지여부와 File Sequence Check Option값 이다.
1.FileSystem Device Name(파일시스템장치명)
파일시스템장치명은 곧 파티션들의 위치를 말합니다. 위에 fdisk -l를 처서 나온 부분을 보시면 /dev/sdb1~6까지의 파티션장치의 위치 즉, 주소를 나타내는것이 보일겁니다.
이러한 장치면을 써주는 필드입니다. 그대로 /dev/sdb1이런식으로 쓸수도있지만
라벨(Label)을 이용해서도 사용 가능합니다. 다른 항목들 소개후 라벨과 장치명 모두 사용하는 예를 들어보도록 할께요.
2.Mount Point(마운트포인트)
등록할 파티션을 어디에 위치한 디렉토리에 연결할것인지 설정하는 필드입니다.
마운트 시켜줄 디렉토리 경로를 써주시면되요.
3.FileSystem Type(파일시스템 종류)
파티션 생성시 정해줬떤 파일시스템의 종류를 써주는 필드입니다. 저희는 ext3으로 파일시스템을 설정하였기때문에 ext3을써줘야 합니다. 일단 파일시스템은 무슨 종류들이 있는지 소개해드리도록 할께요.
ext -초기 리눅스에서 사용하였던 종류, 현재는 사용하지 않습니다.
ext2 -현재도 사용하며, 긴~파일시스템이름을 지원하는것이 특징입니다.
ext3 -저널링 파일시스템, ext2보다 파일시스템의 복수/보안기능을 크게향상되었고
현재 기본 파일시스템으로 쓰이고 있습니다.
ext4 -16TB까지만 지원하던 ext3과 달리 더큰 용량을 지원하며, 삭제된 파일 복구,
파일 시스템 점검속도가 훨~씬 빨라진 파일시스템입니다.
iso9660 -DVD/CD-ROM을 위한 표준 파일시스템으로 읽기만 가능합니다.
nfs -원격서버에서 파일시스템 마운트할때 사용하는 시스템(Network File System)
swap -스왑파일시스템, 스왑공간으로 사용되는 파일시스템에 사용합니다.
ufs -Unix system에서 표준 파일시스템으로 사용합니다.(Unix File System)
3년전 구입해 가지고 있던 Pandaboard-es에 안드로이드를 올려서 가지고 놀아보고자, 다시 꺼내었다.
SD카드 파티셔닝/포맷 후에 u-boot와 MLO를 넣고 booting 시도했으나 실패.
serial연결해도 booting log조차 출력되지 않는 상황이었다.
오랫동안 사용하지 않은 보드의 H/W 적인 문제가 아닌가 고민하다가 pandaboard.org 에서 검색해보니 아래와 같이 H/W의 문제인지 아닌지를 판단할 수 있도록 pre-built 된 u-boot이미지, MLO, 그리고 kernel을 제공하고 있었다.
또한 제공된 이미지 안에 H/W test를 위한 쉘스크립트가 '/bin' 아래에 'panda-test.sh' 라는 이름으로 함께 제공되고 있어서 실행만 하면 다음 항목들에 대해 간단히 정상동작 유무를 확인 가능했다.
참고로 9번 WLAN은 manual test 를 해야한다.
Test Case List
Framebuffer
Display
Audio Out
HDMI Audio
LED1&2
USB Thumb Drive RW test
EHCI
LAN9514
WLAN (802.11 b/g/n)
아래는 pandabaord-es 가 정상적으로 부팅되지 않는 상황에서 시도해 볼 수 있는 조치이다.
준비물
1. 테스트 환경 부팅이미지 (validation.img)
2. Win32DisImager (호스트 머신이 윈도우 환경인 경우만)
Reformatting an SD Card
Often users tend to incorrectly format an SD card and end up with a bad SD card. In this situation, we recommend that you use a new SD card and reformat the card. Review "How to format your SD card" for instructions. Then try to load your binaries again and see if that solves your problem.
Validation Environment
If you suspect your PandaBoard / PandaBoard ES has a hardware issue. You can use the following validation environment to run a set of testcases on the board. These tests must be run before you submit a RMA form also.
Download the validation environment, install and boot it on your working SD card using below instructions:
rfc951.txt
