[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)

by Blogger 하얀쿠아
2017. 5. 7. 12:36 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)


위의 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바이트 길이이기 때문에, 일반적으로 이는 문제가 되지 않는다.




이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 클라이언트/서버의 메세지전송과 주소설정 방법

by Blogger 하얀쿠아
2017. 5. 7. 11:57 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서: BOOTP 클라이언트/서버의 메세지전송과 주소설정

BOOTP는 다양한 장치에 사용할 수 있지만, 최초 개발의 주된 동기 중 하나는 저장 장치가 없는 "멍청한"장치를 자동으로 구성하는 방법을 제공하는 것이었다.

대부분 이러한 멍청한 장치들은, 비교적 제한된 기능만을 가지고 있기때문에, 근사한 부팅 프로토콜을 지원하도록 요구하는 것은 사실 말이 되지않았다.

따라서 BOOTP는 복잡한 개념이나 근사한 개념 혹은 근사한 구현 요구사항 없이, 호스트 구성을 수행하는 복잡하지 않은 프로토콜이다.



BOOTP 클라이언트 및 서버

다른 많은 TCP / IP 프로토콜과 마찬가지로 BOOTP는 실제로 클라이언트 / 서버이다.
프로토콜의 작동은 BOOTP 클라이언트와 BOOTP 서버 간의 단일 메시지 교환으로 구성된다.

BOOTP 클라이언트는 구성해야하는 모든 유형의 장치가 될 수 있다.
BOOTP 서버는 BOOTP 클라이언트 요청에 응답하도록 특별히 설정된 네트워크 장치이며, 주소 지정 및 필요한 경우 클라이언트에 제공 할 수 있는 기타 정보로 프로그램이 구현된다.

BOOTP 서버는 서비스를 제공하는 클라이언트에 대한 특별한 정보 집합을 유지 관리한다.
여기에서 하나의 핵심 부분은 테이블이다.
이 테이블은 각 클라이언트의 하드웨어 (Layer 2, 데이터 링크 계층) 주소, 즉 MAC주소를 해당 장치에 할당 하고자 하는 IP 주소로 매핑하는 테이블이다.

클라이언트는 요청에서 하드웨어 주소를 지정하고, 서버는 이 주소를 사용하여 클라이언트의 IP 주소를 찾아서 클라이언트로 응답한다.
물론, 구현하기에 따라 다르고, 다른 기술도 사용할 수도 있겠지만, 매핑 테이블이 가장 일반적인 구현방법이다.


메시지 및 전송

그런데, BOOTP 메시징은 몇 가지 이유로인해, 계층 4 전송 프로토콜로 TCP가 아닌 UDP (User Datagram Protocol)를 사용한다. 

첫째, UDP는 다른 레이어 4 전송 프로토콜인 TCP보다 훨씬 덜 복잡하며, BOOTP와 같은 간단한 "요청 / 응답"프로토콜에 이상적이다.

둘째, 클라이언트가 분명히 BOOTP 서버의 주소를 알지 못하기 때문에 요청은 로컬 네트워크에서 브로드 캐스팅되야 한다.
UDP는 브로드 캐스트를 지원하지만 TCP는 브로드 캐스트를 지원하지 않는다.
BOOTP를 공부하는 정도라면 여러분들은 이미 알고 있을 것이다.

UDP는 BOOTP 서버에 대해 잘 알려진 (예약 된) 포트 번호 인 UDP 포트 67을 사용한다.
BOOTP 서버는 클라이언트가 보낸 이러한 브로드 캐스트 BOOTP 요청에 대해 포트 67에서 "수신 대기"한다.
요청을 처리 한 후 서버는 클라이언트에게 응답을 보낸다.
이 처리 방법은 클라이언트가 자체 주소를 알고 있는지 여부에 따라 다르다.


◎ 클라이언트가 주소를 알고 있는 경우
BOOTP 클라이언트가 이미 자신의 주소를 알고있는 경우가 있다. 이 경우는, BOOTP 서버가 이 주소를 직접 응답을 다시 보낼 때 사용할 수 있다.


◎ 클라이언트는 자신의 주소를 모르는 경우
물론 BOOTP는 주소를 모르는 클라이언트에게 IP 주소를 제공하기 위해 흔히 사용 된다. 
이것은 종종 "닭고기와 계란"문제라고 불리는데, 그 이유는 "닭고기와 계란"이라는 오래된 수수께끼와 같은 종류의 "고리"를 나타내기 때문이다.
이 딜레마를 해결하기 위해 BOOTP 서버에는 두 가지 선택지가 있다.
운영체제가 이를 지원하면 서버는 클라이언트의 하드웨어 주소를 사용하여 장치에 대한 ARP 항목을 만든 다음 레이어 2 유니 캐스트를 사용하여 응답을 전달할 수 있다.
그렇지 않으면 회신을 로컬 네트워크에서 브로드 캐스트로 전송해야한다.



브로드 캐스트 및 포트 사용

BOOTP 서버가 클라이언트로 다시 브로드캐스트 해야한다는 사실은 대부분의 TCP/IP 프로토콜이 클라이언트 포트를 사용하는 방식에서 약간의 변화가 필요하다.
일반적으로 클라이언트/서버 트랜잭션에 UDP 또는 TCP를 사용하는 클라이언트는 임시 또는 잠시사용하기 위한 포트 번호를 생성하여 요청메세지의 소스포트로 사용한다.

서버는 그 임시 포트 번호를 사용하여 클라이언트의 IP 주소로 응답을 보낸다.
임시 포트 번호는 특정 IP 주소에 대해 고유해야하지만, 네트워크의 모든 장치에서 고유하지는 않는다.

이해하기 쉽게 한가지 예를 들어 보면, 이런것이다.
하나의 네트워크상에 두 장치 A, B가 있다.
장치 A는 웹 서버에 대한 HTTP 요청에 임시 포트 번호 1248을 사용하고, 장치 B는 TCP/IP 스택에서 포트 번호 1248을 사용하여 DNS 요청을 보낼 수 있다.
서로다른 장치가, 동일한 네트워크상에 있다 하더라도, 동일한 포트 1248을 사용할 수 있다는 것이다.

BOOTP의 서버가 브로드캐스트이기 때문에 유니캐스트 전송을 사용하는 특정 장치를 대상으로하지 않는다.
즉, 일시적인 포트 번호로 안전하게 보낼 수 없다는 것을 의미한다.

네트워크상의 다른 장치는 다른 트랜잭션에 대해 동일한 임시 포트 번호를 선택했을 수 있으며 BOOTP 서버의 응답을 실수로 자기에게 보낸것으로 오인 할 수 있다.
이 문제를 피하기 위해 잘 알려진 다른 포트 번호가 BOOTP 클라이언트에만 사용된다.
UDP 포트 68 이 바로 그것이다.

클라이언트는 브로드캐스트 또는 유니캐스트 전송을 위해서 이 포트에서 수신 대기하지만, BOOTP 요청을 보낸적이 없는 클라이언트는 무시할 것이다. 
이 "이중 브로드 캐스트"BOOTP 통신 프로세스는 아래 그림에 나와 있으니 참고하자.

General Operation Of the Boot Protocol

이 그림을 간단히 설명하겠다.

장치 A는 IP 주소 및 기타 매개 변수를 확인하려고 시도하고 있다.

UDP 포트 67을 사용하여 로컬 네트워크에서 BOOTP 요청을 브로드캐스트 한 다음 포트 68에서 응답을 수신한다.

장치 D는 BOOTP 서버로 구성되어있고, 67 포트에서 수신 대기한다.

요청을 받으면 포트 68에서 A에게 IP 주소가 무엇인지 알려주는 브로드캐스트를 보낸다.

BOOTP는 브로드 캐스트를 사용하여 할당 된 IP 주소가없는 장치와의 통신을 허용하는 비교적 간단한 클라이언트/서버 프로토콜임을 생각하면 매우 간단한 과정이다.



세줄 요약 주요 개념

  1. BOOTP 클라이언트는 브로드 캐스트를 사용하여 청취 BOOTP 서버에 요청을 보낸다.
  2. 대부분의 경우 BOOTP 클라이언트 장치는 프로토콜을 사용할 때 자체 IP 주소를 알지 못한다. 
  3. 이런 이유 때문에 BOOTP 서버는 일반적으로 응답을 전송할 때 브로드 캐스트를 사용하여 클라이언트에 도달하는지 확인한다.

손실 된 메시지의 재전송

BOOTP 메시지 전송을 단순하게 하기위해 UDP를 사용할때의 단점은 전송 품질을 보장할 수 없다는 것이다.

UDP특성을 이미 알고 있겠지만, UDP는 신뢰할 수 없다.

즉, BOOTP 클라이언트로부터 전송된 요청메세지가 서버에 도착하기 전에 손실될수도 있고, 운좋게 서버에 도착했더라도, 클라이언트 방향으로 전송된 서버의 응답 메세지가  도착하지 않을 수 있다. 



이쯤 읽으면 '응? 장난하냐??' 하는 생각이 들겠지만, 진정하고 계속 읽어보자.

BOOTP는 이에대한 대비책을 가지고 있다.



UDP를 사용하는 다른 프로토콜과 마찬가지로 BOOTP 클라이언트도 재전송 타이머를 사용하여이 문제를 처리한다.

클라이언트가 일정 기간 후에 응답을받지 못하면 클라이언트는 요청을 다시 보낸다.


그러나 BOOTP 클라이언트는 재전송 전략을 구현하는 방법에 주의를 기울여야 한다.

한가지 문제시나리오를 가정해보자.
200대의 BOOTP 클라이언트가 있는 네트워크에서, 200대의 모든 클라이언트 전원이 꺼진다고 가정하겠다.
이 기계들은 거의 모두 비슷하게(심지어 동일하게) BOOTP가 구현되었을 것이기 때문에 전원이 다시 켜지면, 모두 재시작되며 거의 동시에 BOOTP 요청을 보내려고 할것이다.
왜? 구현이 동일하니깐.

대부분 이러한 문제로 인해 문제가 발생할 수 있다.
BOOTP 요청 메세지 일부가 손실되기도 할것이고, 심지어 서버가 과부하로 인해 일부 메세지를 drop해야 할 수도 있다. 
서버의 패킷큐 overflow 등의 이유가 예상된다.

그런데 모든 클라이언트는 전송을 실패했으므로 재전송을 하려 할 것이다.
이때, 각각의 클라이언트가 재전송을 위해 동일한 시간을 기다렸다가 재전송을 하게된다면?
그 시간이 지나면 모든 기계가 요청을 다시 보낼것이므로, 동일한 문제를 반복하게 될것이다. ...야 이 멍청이들아!!??

이와 같은 상황을 회피하기 위해 BOOTP 표준에서는 재전송주기 시간 값을 4 초부터 시작해서, 연속 시도를 위해 이 값을 지수적인 증가, 즉 두 배로 증가, 시키는 백 오프(Back-off) 방식을 사용할 것을 권장한다.
재전송을 위해서 말이다.
또한, 여러대의 BOOTP 클라이언트가 동시에 재전송을 하는 중첩 상황을 피할 수 있게 임의성 요소가 추가된다.
이 아이디어는 이더넷(ethernet)에서 사용되는 백 오프 방법과 매우 유사하다. 실제로 BOOTP 표준은 이더넷의 사양서(Specification)를 참조한다.

예를 들어, 첫 번째 재전송은 0에서 4 초 사이의 임의의 시간 간격 후에 발생시킨다. (임의의 양을 더하거나 뺀 값). 
필요한 경우 두 번째 재전송에서는, 0과 8 초 사이의 임의의 시간 간격에서 플러스 또는 마이너스 하는 등...
이렇게하면 재전송이 손실되는 가능성을 줄이는 데 도움이 되며, BOOTP의 과도한 트래픽으로 인해 네트워크가 중단되지 않도록 할 수 있다.




이 댓글을 비밀 댓글로

eth0 에 고정 IP 주소할당하기(static IP address)

by Blogger 하얀쿠아
2017. 1. 18. 00:52 소프트웨어 Note/Embedded Linux


문제

요약: eth0 에 고정 IP주소(static IP address)를 할당하고자 한다.


지난번 포스팅(http://techlog.gurucat.net/277)을 하면서 판다보드에서 살린 두개의 network interface중에서 eth0 에 '192.168.1.1' 과 같이 고정 IP를 할당하고 싶다.

이유는 PC와 판다보드를 LAN cable을 통해 direct연결 한 후, putty와 같은 툴을 사용해서 ssh shell로 연결 하여 개발을 진행하려고 하는 것이다.

판다보드를 부팅한 후, eth0 에 어떻게 고정 IP를 할당할 수 있는가?


해결


할당하려는 IP는 192.168.1.1 이다.


원래는 bootloader에서 argument 읽은 후 kernel로 argument 전달하는 방식을 택하려 했으나, 일단은 더 간단한 방법을 선택했다.


우선 /etc/network/interfaces 를 편집기로 연다.


root@arm:~# cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d


auto lo

iface lo inet loopback


allow-hotplug eth0

iface eth0 inet static

address 192.168.1.1

netmask 255.255.255.0

gateway 192.168.1.255


allow-hotplug wlan0

iface wlan0 inet dhcp


파란 색으로 표시한 것과 같이 기술해 준다.


이상.



재부팅을 하고 확인해보면 아래와 같이 ip address가 할당된 것을 볼 수 있다.


root@arm:~# ifconfig

eth0      Link encap:Ethernet  HWaddr c6:f3:ca:97:cf:67

          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::c4f3:caff:fe97:cf67/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:226 errors:0 dropped:0 overruns:0 frame:0

          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:18954 (18.9 KB)  TX bytes:4397 (4.3 KB)


lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


wlan0     Link encap:Ethernet  HWaddr de:ad:be:ef:00:00

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


그런데.. 문제가 있다.

sshd 가 부팅되면서 시작되었다가 곧바로 종료된다.

그래서 ssh shell을 사용하지 못하고, 아직 serial로 연결해서 작업을 진행중이다.



Next Action Item


sshd의 시작 직후 종료되는 원인을 찾고, sshd가 부팅되면서 정상적으로 실행되도록 수정하는 것이다.

이 댓글을 비밀 댓글로

[임베디드/판다보드] Networking Interface Initialize

by Blogger 하얀쿠아
2017. 1. 10. 21:33 소프트웨어 Note/Embedded Linux


문제현상

판다보드에서 리눅스를 부팅한 후, 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 되도록 하는 방법이 있을 텐데 비활성화 되어 있는 것 같다.

어느 부분을 수정해야 하는지 내가 모르고 있는 것 같아서, 찾아보았다.


해결


우선 판다보드의 네트워크 인터페이스를 확인해보았다.


root@arm:~# ls -l /sys/class/net/

total 0

lrwxrwxrwx 1 root root 0 Feb 11 16:28 eth0 -> ../../devices/platform/44000000.ocp/4a064000.usbhshost/4a064c00.ehci/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0

lrwxrwxrwx 1 root root 0 Feb 11 16:28 lo -> ../../devices/virtual/net/lo

lrwxrwxrwx 1 root root 0 Feb 11 16:28 wlan0 -> ../../devices/platform/44000000.ocp/480d5000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:2/wl12xx.2.auto/net/wlan0




wlan0와 eth0는 존재하는걸 확인했다.

Wi-Fi를 위한 firmware는 rootfs만드는 과정에서 미리 /lib/firmware/ti-connectivity 에 받아 두었으므로 따로 준비할 필요는 없는 상황이다.


root@arm:~# ls -l /lib/firmware/ti-connectivity/

total 8792

-rw-r--r-- 1 root root  48909 Sep 18  2016 TIInit_7.2.31.bts

-rw-r--r-- 1 root root 194180 Apr 25  2016 wl1251-fw.bin

-rw-r--r-- 1 root root    752 Apr 25  2016 wl1251-nvs.bin

-rw-r--r-- 1 root root 273880 Sep 18  2016 wl1271-fw-2.bin

-rw-r--r-- 1 root root 272836 Sep 18  2016 wl1271-fw-ap.bin

-rw-r--r-- 1 root root 271832 Sep 18  2016 wl1271-fw.bin

lrwxrwxrwx 1 root root     14 Jul 21  2016 wl1271-nvs.bin -> wl127x-nvs.bin

-rw-r--r-- 1 root root 280388 Sep 18  2016 wl127x-fw-3.bin

-rw-r--r-- 1 root root 260852 Apr 25  2016 wl127x-fw-4-mr.bin

-rw-r--r-- 1 root root 261892 Apr 25  2016 wl127x-fw-4-plt.bin

-rw-r--r-- 1 root root 276684 Apr 25  2016 wl127x-fw-4-sr.bin

-rw-r--r-- 1 root root 354600 Apr 25  2016 wl127x-fw-5-mr.bin

-rw-r--r-- 1 root root 352588 Apr 25  2016 wl127x-fw-5-plt.bin

-rw-r--r-- 1 root root 370996 Apr 25  2016 wl127x-fw-5-sr.bin

-rw-r--r-- 1 root root 267496 Sep 18  2016 wl127x-fw-plt-3.bin

-rw-r--r-- 1 root root    912 Jul 21  2016 wl127x-nvs.bin

-rw-r--r-- 1 root root 284784 Sep 18  2016 wl128x-fw-3.bin

-rw-r--r-- 1 root root 264904 Apr 25  2016 wl128x-fw-4-mr.bin

-rw-r--r-- 1 root root 269424 Apr 25  2016 wl128x-fw-4-plt.bin

-rw-r--r-- 1 root root 284156 Apr 25  2016 wl128x-fw-4-sr.bin

-rw-r--r-- 1 root root 359140 Apr 25  2016 wl128x-fw-5-mr.bin

-rw-r--r-- 1 root root 360452 Apr 25  2016 wl128x-fw-5-plt.bin

-rw-r--r-- 1 root root 378988 Apr 25  2016 wl128x-fw-5-sr.bin

-rw-r--r-- 1 root root 265460 Sep 18  2016 wl128x-fw-ap.bin

-rw-r--r-- 1 root root 273324 Sep 18  2016 wl128x-fw.bin

-rw-r--r-- 1 root root 271932 Sep 18  2016 wl128x-fw-plt-3.bin

-rw-r--r-- 1 root root   1113 Jul 21  2016 wl128x-nvs.bin

lrwxrwxrwx 1 root root     14 Jul 21  2016 wl12xx-nvs.bin -> wl127x-nvs.bin

-rw-r--r-- 1 root root 639276 Apr 25  2016 wl18xx-fw-2.bin

-rw-r--r-- 1 root root 673328 Apr 25  2016 wl18xx-fw-3.bin

-rw-r--r-- 1 root root 745228 Dec 31  2016 wl18xx-fw-4.bin

-rw-r--r-- 1 root root 413860 Sep 18  2016 wl18xx-fw.bin




우선 interface 파일을 확인해보았다.


root@arm:~# ls -l /etc/network/interfaces

-rw-r--r-- 1 root root 261 Feb 11 16:32 /etc/network/interfaces

root@arm:~# cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d


auto lo

iface lo inet loopback




'lo' 인터페이스에 대해서만 설정되고 있는 것이 보인다.

이 파일을 열고 eth0와 wlan0에 대한 내용을 추가했다.


root@arm:~# cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d


auto lo

iface lo inet loopback


allow-hotplug eth0

iface eth0 inet manual


allow-hotplug wlan0

iface wlan0 inet dhcp




재부팅을 한 후 ifconfig로 확인해보면 아래와 같이 추가된 인터페이스를 확인 할 수 있다.


root@arm:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 8e:16:3e:3d:2b:e5

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


wlan0     Link encap:Ethernet  HWaddr de:ad:be:ef:00:00

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)



작업하면서 시행착오를 겪은 부분이 있는데,

allow-hotplug가 아닌 auto eth0, auto wlan0 로 추가를 했더니, 부팅과정에서 커널 로드 후 systemd가 각 service 파일을 차례로 시작하다가 interface up하는 부분에서 무한 대기상태로 빠지는 것이었다.


문득, interface up을 담당하는 service가 어떤건지 궁금해졌다.
현재 판다보드에서 동작중인 리눅스는 ubuntu 16.04 이다.
정확하게 어떤 버전부터인지는 모르겠으나 ubuntu 16.04는 기존의 init.d script를 systemd로 대체한 것으로 보인다.

root@arm:~# ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Sep  7  2016 /sbin/init -> /lib/systemd/systemd


systemd에 대한 자세한 내용은 다른 포스팅에서 다루어 보고자 한다.
일단, systemd는 커맨드라인에서 인터페이스 툴을 제공해 주고 있는데, 그 이름은 'systemctl' 이다.
이 툴을 사용해서 networking service 에 대한 정보를 확인해보았다.

root@arm:~# systemctl cat networking
# /lib/systemd/system/networking.service
[Unit]
Description=Raise network interfaces
Documentation=man:interfaces(5)
DefaultDependencies=no
Wants=network.target
After=local-fs.target network-pre.target apparmor.service systemd-sysctl.service
Before=network.target shutdown.target network-online.target
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery
ExecStart=/sbin/ifup -a --read-environment
ExecStop=/sbin/ifdown -a --read-environment
RemainAfterExit=true
TimeoutStartSec=5min

# /run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
# Automatically generated by systemd-insserv-generator

[Unit]
Wants=network.target
Before=network.target


systemctl cat 은 각 service unit의 동작방식을 정의한 파일의 내용을 보여주는 명령이다.

간단히 설명 부분만 확인해보면, 'Raise network interfaces' , 찾았다 요놈.

네트워크 인터페이스를 올려주는 놈이란다.

내가 찾던 놈이구만.


Type=oneshot 인 걸로 봐서, 부팅될 때 한번만 실행 하고 끝내는 놈이지 싶다.

확인해봐야지.

networking service상태에 대해 살펴보자.


root@arm:~# systemctl status networking

● networking.service - Raise network interfaces

   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor prese

  Drop-In: /run/systemd/generator/networking.service.d

           └─50-insserv.conf-$network.conf

   Active: active (exited) since Thu 2016-02-11 16:28:07 UTC; 27min ago

     Docs: man:interfaces(5)

  Process: 284 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0

  Process: 262 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [

 Main PID: 284 (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/networking.service


Feb 11 16:28:05 arm systemd[1]: Starting Raise network interfaces...

Feb 11 16:28:07 arm systemd[1]: Started Raise network interfaces.


자세히는 모르겠지만, 대충 살펴보면, load 되었고, active 상태인데, exited 상태이기도 하다.

그 아래를 보면, 284 PID를 갖는 process로 /sbin/ifup 을 실행 했던 것으로 보인다.

argument로 --read-environment 라는게 있는 걸로 보아, 뭔가 환경변수나 환경설정을 읽어서 interface up 을 했을 것으로 추정된다.


좋아, 다시 보자.

'systemctl cat networking' 을 통해 확인 했던 부분중에,

EnvironmentFile=-/etc/default/networking 라는 부분이 있는 것을 발견했다.


root@arm:~# cat /etc/default/networking

# Configuration for networking init script being run during

# the boot sequence


# Set to 'no' to skip interfaces configuration on boot

#CONFIGURE_INTERFACES=yes


# Don't configure these interfaces. Shell wildcards supported/

#EXCLUDE_INTERFACES=


# Set to 'yes' to enable additional verbosity

#VERBOSE=no


별다른 내용은 없는데, 주석들을 읽어보면, boot sequence 동안에 실행되는 networking init script의 설정파일쯤 되는놈인것 같다.

그런데 죄다 주석처리되어서, 딱히 하는 일은 없는 것으로 보인다.

OK. 이놈은 통과..


현재 내가 궁금한 것은 '/etc/network/interfaces' 이놈을 누가 읽는가 하는 부분인데.

ifup이 읽는 default 파일인 것으로 추정된다.. 

ifup --help 로 확인해보면 아래와 같다.


root@arm:/lib/systemd/system# ifup --help

Usage: ifup <options> <ifaces...>


Options:

        -h, --help             this help

        -V, --version          copyright and version information

        -a, --all              process all interfaces marked "auto"

        --allow CLASS          ignore non-"allow-CLASS" interfaces

        -i, --interfaces FILE  use FILE for interface definitions

        -X, --exclude PATTERN  exclude interfaces from the list of

                               interfaces to operate on by a PATTERN

        -n, --no-act           print out what would happen, but don't do it

                               (note that this option doesn't disable mappings)

        -v, --verbose          print out what would happen before doing it

        -o OPTION=VALUE        set OPTION to VALUE as though it were in

                               /etc/network/interfaces

        --no-mappings          don't run any mappings

        --no-scripts           don't run any hook scripts

        --no-loopback          don't act specially on the loopback device

        --force                force de/configuration

        --ignore-errors        ignore errors


-a 옵션은 'auto' 로 표시된 모든 인터페이스를 처리한다는 옵션이다.

--read-environment 라는 옵션은 없다.


또한 설명에 /etc/network/interfaces 에 대한 내용이 있는 걸로 미루어 봐서, interface 정의 하는 default 파일경로인 것 같다.


Next Action Item

이제 해보려는 작업은 두가지다.

1. eth0 에 '192.168.1.1' 이라는 ip를 boot argument로 설정되도록 하는 작업 ( 바로가기 )

2. wlan0 와 연동해서 Wi-Fi stack (wpa-supplicant)을 booting time에 실행되도록 하는 작업



이 댓글을 비밀 댓글로

Kernel command line 보는 방법

by Blogger 하얀쿠아
2017. 1. 5. 01:44 소프트웨어 Note/Embedded Linux

Linux kernel command line, boot argument


동작중인 kernel의 shell상에서 command line parameter를 보는 방법은 아래와 같다.

이를 'boot arguments' 라고도 한다.


$ cat /proc/cmdline


여기에는 linux kernel이 부팅할 때 필요한 여러가지 정보들을 kernel에게 넘겨주는 형태로 사용한다.

예를들면 root device나 network configuration등에 대한 정보들 말이다.


boot loader에서 linux kernel로 변수정보 넘기기

boot loader에서 linux kernel로 정보를 넘길때도 사용할 수 있다.

U-boot 에서는 'bootargs' 라는 변수의 값을 자동으로 linux kernel 부팅시키면서 넘긴다.

U-boot command line에서 아래와 같이 환경변수를 선언하면, bootargs 뒤의 'root=/dev/ram rw' 가 bootargs의 내용이 되며, 이 값이 kernel로 전달된다.


setenv bootargs root=/dev/ram rw


참고로 U-boot 는 Hush shell을 사용한다. (bourne shell과 유사함)


참고 : http://www.denx.de/wiki/DULG/LinuxKernelArgs

이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP란? BOOTP 특성?

by Blogger 하얀쿠아
2016. 12. 30. 02:19 소프트웨어 Note/Embedded Linux

BOOTP란? (bootstrap protocol)


Bootp는 TCP/IP상에서 자동 부팅을 위한 최초의 표준프로토콜이다.

디스크 장치가 없는 클라이언트를 구동시키기 위한 목적으로 개발되었다.

여기서, 디스크 장치가 없는 클라이언트라고 하면, 과거 Unix머신과 연결해서 사용하던 'X터미널' 과 같은 장비쯤 되시겠다.

이 터미널 장비는 디스크 장치가 없으므로, 장치의 설정정보를 저장할 곳이 마땅치 않게된다. 


그러니깐, 디스크 장치를 가지고 있는 Main Unix머신이 이 정보를 가지고 있다가, X터미널이 실행되고 Unix머신에게 연결하려고 신호를 보내면, Unix머신은 Bootp 서버를 이용해서 X터미널에게 이런 정보들을 알려주게 된다.

그러면 X터미널은 BOOTP클라이언트 쯤이 된다.

정확하게 말하면 클라이언트는(X터미널) BOOTP를 통해 3가지 정보를 제공받는다.


  1. IP주소
  2. 부트 파일이 있는 서버 이름
  3. 부트 파일 이름

하위 프로토콜로 UDP와 IP 프로토콜을 사용한다.


사실 BOOTP는 지금은 거의 사용되지 않는 구형 프로토콜이긴 하다.

이후 좀더 진보된 네트워크 관리 프로토콜이 DHCP의 기반이 된다.

게다가, BOOTP - DHCP가 완벽호환 되는 특징이 있어서,  BOOTP 클라이언트가 DHCP 서버와 통신이 가능하다.


만약 당신이 DHCP를 들어본적이 없다면, 당장은 간단히 설명하겠다.

DHCP는 '내가 누구?, 여긴 어디?' 에 대한 정보를 주는 프로토콜 쯤으로 이해해두자. 

즉, IP address, subnet mask address, DNS address, gateway address 와 같은 네트워크 그룹에 가입하기 위해 필요한 정보나, domain상에서 통용되는 터미널의 이름 등..을 전달해 준다고 보면 된다.


임베디드 개발보드에서는 tftp와 함께 사용되곤 한다.

즉, Bootloader에서 Kernel과 파일시스템 Image를 Host PC에서 Target board로 다운로드할 때, Host PC에 연결하기 위한 정보가 필요한데,

Bootp를 이용하면 Target board의 IP와 Host에 대한 정보를 Host PC에서 가져올 수 있도록 하는게 가능하다.



BOOTP 특성

몇가지 특성을 알면, BOOTP를 깊게 이해하는데 좀 더 수월할 것이다.


BOOTP는 클라이언트 - 서버 구조로 동작한다.


그리고 정적인 주소 설정 방식을 사용한다.

여기서 '정적인 주소 설정 방식' 이 무엇이냐면, 관리자에 의해 미리 정의되어있는 '물리주소 - IP주소' 간 매핑 테이블을 사용하는 방식이라고 생각하면된다.


또한 UDP에 의해 캡슐화 되고, 보통 TFTP와 함께 동작한다.

클라이언트 요청은 UDP 포트 68로 전달되고, 서버 응답은 UDP 포트 67로 전달된다.

요청메세지는 브로드캐스트로 전송되며, Source IP Address는 0.0.0.0 , Destination IP Address는 255.255.255.255 로 설정한다.


UDP로 전달되는 메세지 유실에 대한 대비책으로써, 재전송(Retransmission)과 시간초과(Timeout) 정책을 이용한다.

주소 설정 방식과, 재전송 등에 대해서는 아래 세부섹션에서 좀더 살펴보자.




BOOTP 의 RFC document

만약, 당신이 굉장히 네트워크에 관심이 많은 사람이어서, 

BOOTP에 대해 자세히 알고 싶다면 RFC 951와 RFC 1542를 참고하기 바란다.


일반적으로 RFC문서는 아래 주소에서 찾을 수 있다.


RFC문서 검색기 페이지 : https://www.rfc-editor.org/search/rfc_search.php




귀찮다면, 아래를 다운받자.


RFC 951 -- The Bootstrap Protocol (BOOTP) (ftp://nic.ddn.mil/rfc/rfc951.txt)

rfc951.txt


RFC 1542 Clarifications and Extensions for the Bootstrap ProtocolClarifications and Extensions for the Bootstrap Protocol

rfc1542.txt




또한, IETF라는 기구가 있다. '국제 인터넷 표준화 기구' 쯤으로 해석한다.

IETF는 Internet Engineering Task Force의 머릿글자이다.

이는 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업기구이다.

계속 관심이 간다면, 아래 홈페이지에서 rfc에 대한 몇몇 정보를 찾아보자.


IETF Homepage : http://www.ietf.org/rfc.html






Tftp 란


TFTP (Trivial File Transfer Protocol) 은 FTP와 같은 파일 전송 프로토콜이다.

하위 프로토콜로 IP, UDP프로토콜을 사용한다.

개발보드에서는 Bootloader에서 Kernel과 파일시스템 Image를 Host에서 Target으로 이더넷을 통하여 고속으로 다운로드하기 위해 사용한다.



Bootp와 Tftp를 활용한 개발보드의 초기 부팅방법


구체적인 활용 방법에 대해서는 기회가 된다면 내용을 추가하도록 하겠다.




이 댓글을 비밀 댓글로
    • 지나가던
    • 2019.11.21 12:35
    진정으로 저에게 도움되는 글 입니다. 감사합니다.

PandaBoard ES : 부팅용 SD card 준비

by Blogger 하얀쿠아
2016. 12. 16. 00:50 소프트웨어 Note/Embedded Linux

PandaBoard ES : 보드 부팅을 위한 SD card 준비


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


jeon@ubuntu:~$ sudo mkfs.ext4 -L rootfs /dev/sdc2
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: 1257cd67-576f-47f8-a55b-d2c8c2a81539
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                           
Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done


jeon@ubuntu:~$ sudo mkfs.ext4 -L data /dev/sdc3
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 524288 4k blocks and 131072 inodes
Filesystem UUID: c38ba4aa-a430-4d3f-b5ca-d5edce08379f
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912

Allocating group tables: done                           
Writing inode tables: done                           
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done


jeon@ubuntu:~$ sudo mkswap -c -L swap /dev/sdc4
0 bad pages
Setting up swapspace version 1, size = 1.7 GiB (1760030720 bytes)
LABEL=swap, UUID=fa0383da-57ed-4a06-8e9a-e4a4a3659b85



커널 소스 확보 및 빌드


Pandaboard ES에서 사용할 커널이미지를 만들기 위해서, 직접 커널 소스를 빌드하기로 했다.

최대한 그런 일은 없어야 겠지만, 커널 수정이 필요할 경우가 발생하면... 수정의 용이성을 위해서이다.

만약 미리 빌드된 커널이미지를 보드에 올려서 사용한다면, 커널 수정이 필요한 순간, 일치하는 커널 소스를 찾고 빌드환경 만들고... 좀 번거로울 것이기 때문에.

처음부터 미리 번거롭기로 했다.(?)


CPU architecture 별로 커널 빌드를 위한 스크립트를 제공하는 고마운 git 저장소가 있다.



https://github.com/RobertCNelson/armv7-multiplatform/tree/v4.9.x



/dev/sdc2로 root file system 복사

ubuntu 16.04 LTS의 file system을 구해서 2번째 파티션 (리눅스의 root파티션)에 복사해 넣었다.

리눅스의 커널이미지와는 별개로, 우리는 리눅스 배포판의 root file system이 필요하다.

왜 이런 작업이 필요하나면...

커널이미지는 말그대로 커널부분만을 제공한다.

다시말하면 /usr/bin/ 에 존재하는 실행파일들... 즉 여러가지 커맨드들을 사용한다거나..

/etc 아래 존재하는 리눅스의 설정파일등을 통해 리눅스 설정을 한다거나...

systemd등을 통해 부팅시점에 여러가지 데몬들을 띄우거나 소켓을 생성하거나 ... 등등의 작업들은 커널이미지가 제공하지 않는다는 것이다.

이걸 일일히 코드를 구해서, 크로스컴파일 하고... directory 를 구조에 맞게 만들고... 직접하려면 번거로울 것 이다. 물론 한번 해보면 좋은 경험은 되겠지.


이런 것을 제공하기 위해 누군가가 미리 만들어둔 linux root file system을 구해다가 단순히 sd카드에 복사해 넣는 것으로 끝이다.



다운로드

wget -c https://rcn-ee.com/rootfs/eewiki/minfs/ubuntu-16.04.1-minimal-armhf-2016-09-17.tar.xz



파일 검증

sha256sum ubuntu-16.04.1-minimal-armhf-2016-09-17.tar.xz
2883cdd3416e0bd5988aa351c88db72ca089a184c5a670662d750568ca0869d8  ubuntu-16.04.1-minimal-armhf-2016-09-17.tar.xz


압축해제

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값 이다.



이 댓글을 비밀 댓글로

[Panda Board-es] Trouble shooting: booting에 문제가 있음.

by Blogger 하얀쿠아
2015. 5. 30. 02:15 소프트웨어 Note/Embedded Linux

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


  1. Framebuffer
  2. Display
  3. Audio Out
  4. HDMI Audio
  5. LED1&2
  6. USB Thumb Drive RW test
  7. EHCI
  8. LAN9514
  9. 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:


1. Write the downloaded validation environment (validation.img file) to your SD card by following below instructions:


On Windows machine:

use Win32DiskImager(다운로드) application to write the validation.img.

Make sure you have correctly mapped drive for the SD Card.


On Linux:

Place the SD card at your host computer.

Make sure the SD card is not mounted (just umount it if needed)

Identify the correct raw device name (like /dev/sde - not /dev/sde1)

Run the following command to write it:

       sudo sh -c 'cat ./validation.img | dd bs=4M of=/dev/sde ; sync'

Warning: Some people have reported issues with this method. If this doesn't work, try the following commands:


       sudo dd bs=4M if=validation.img of=/dev/sde

        sync


2. Now boot the board with the sdcard and it should display output from the serial port.


3. Once at the linux prompt cd to "bin" directory and run the panda-test.sh.


NOTES:

You will need to connect a set of speakers/headphones and a USB thumb drive to your PandaBoard before booting the board.

Depending on your display you may or may not hear the HDMI audio test.

All testcases (except WLAN) are automatically run and results displayed on serial console.

You need to manually run the WLAN testcase (see video below on how to do it)

You can review the video and compare your results.


원본 출처 링크 : http://pandaboard.org/content/resources/troubleshooting



잘 모르겠다면, 아래 영상을 참고하자.




아래는 pandaboard-es를 제공된 이미지로 부팅할 때 serial을 통해서 보여지는 부팅로그 이다.

Texas Instruments X-Loader 1.41 (Sep 29 2011 - 10:43:53)
OMAP4460: 1.2 GHz capable SOM
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...


U-Boot 1.1.4-gc1cd80bc-dirty (Oct 12 2011 - 17:56:27)

Load address: 0x80e80000
DRAM:  1024 MB
Flash:  0 kB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
mmc read: Invalid size

4020344 bytes read
## Booting image at 82000000 ...
   Image Name:   Linux-3.0.4+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4020280 Bytes =  3.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.




이 댓글을 비밀 댓글로