기존 이솝 임베디드 포럼의 지식인 서비스가 게시판 형태로 변경되었습니다.
글 수 6,368
예를 들어
호스트 컴퓨터가 있는 상태에서 (리눅스)
usb storage device 를 꽂으면 (storage driver 는 로딩 된 상태로 가정)
제일 최초에 어떻게 커널이 이 device 를 인식하게 되나요?
제가 몇가지 예상을 해봤습니다.
1.usb device 자체에서 host 로 메세지를 보낸다.
2.usb host 에서 주기적으로 탐지 명령어 같은걸 보낸다.
이 두가지 중 하나인 것 같은데
제가 usb 에 대해서 아는 것이 정말 하나도 없는 상태라
device 꽂으면 커널에서 어떻게 인식하고 어떤 루틴이 수행되는지
알려주시면 정말 감사하겠습니다.
작은 정보도 저에겐 큰 도움이 ㅜ_-
감사합니다. 즐거운 주말 보내세요.
--------------------------------------------------
자답입니다.
drivers/usb/core/hub.c 에서 kernel 스레드를 생성하여
hub_thread() 등록하여 돌립니다.
hub_thread() 안의 hub_events() 에서 감지하여
connect_change 변수의 값을 세팅하며
그 후 hub_port_connect_change()함수가 호출되네요.
커널 버젼은 2.6.16
답변 주신분들 감사합니다~!!
호스트 컴퓨터가 있는 상태에서 (리눅스)
usb storage device 를 꽂으면 (storage driver 는 로딩 된 상태로 가정)
제일 최초에 어떻게 커널이 이 device 를 인식하게 되나요?
제가 몇가지 예상을 해봤습니다.
1.usb device 자체에서 host 로 메세지를 보낸다.
2.usb host 에서 주기적으로 탐지 명령어 같은걸 보낸다.
이 두가지 중 하나인 것 같은데
제가 usb 에 대해서 아는 것이 정말 하나도 없는 상태라
device 꽂으면 커널에서 어떻게 인식하고 어떤 루틴이 수행되는지
알려주시면 정말 감사하겠습니다.
작은 정보도 저에겐 큰 도움이 ㅜ_-
감사합니다. 즐거운 주말 보내세요.
--------------------------------------------------
자답입니다.
drivers/usb/core/hub.c 에서 kernel 스레드를 생성하여
hub_thread() 등록하여 돌립니다.
hub_thread() 안의 hub_events() 에서 감지하여
connect_change 변수의 값을 세팅하며
그 후 hub_port_connect_change()함수가 호출되네요.
커널 버젼은 2.6.16
답변 주신분들 감사합니다~!!
아래는 이전에 보던 책의 내용인것 같습니다...
===================================================
일반적 USB 디바이스의 동작
1. 동적인 결합과 제거
호스트는 결합이 감지되면 디바이스가 붙은 허브 포트를 사용가능 하도록 설정시킨다.
디바이스는 리셋되면 다음과 같은 특성을 갖는다.
기본 주소로 응답하게 되고, 디바이스는 설정되지 않으며, 디바이스는 초기에 Suspend 되어 진다.
디바이스가 제거되면 허브는 포트를 사용 불가능시키고 호스트에게 분리되었음을 알리는 통지를 보낸다.
리셋 USB 디바이스는 다음과 같은 세 가지의 특성을 살펴보도록 해야 한다.
1. 기본 USB 주소에 대해 응답
2. 설정되지 않았는지?
3. 초기에 Suspend 되지 않았는지?
디바이스가 허브로부터 제거될 때, 허브는 디바이스가 결합되고 호스트의 제거를 알리는 포트를 사용 불가능하도록 한다.
2. 주소 할당
호스트에 의해 디바이스가 리셋되고 디바이스가 결합된 허브 포트가 인에이블된 후에 호스트는 디바이스에 유일한 주소를 할당한다.
3. 설정
호스트는 디바이스의 성능을 결정하기 위해 디바이스로부터 설정 정보들을 요구한다.
하나의 설정에서 디바이스는 여러 개의 인터페이스들을 가지고 있고, 하나의 인터페이스는 디바이스의 단일 Function 또는 특성을 나타내는 Endpoint 들의 집합으로 되어 있다.
Endpoint 들의 집합과 통신하는데 사용되는 프로토콜과 각각의 Endpoint 의 목적은 공급자가 정의한 특정한 정보이다.
인터페이스는 관련 Endpoint 들의 특성과 개수를 정의하는 여러 가지의 셋팅들을 가지고 있을 수 있으며, 이런 경우 디바이스는 특정 인터페이스에 대한 현재의 교환 가능한 셋팅을 보고하고 선택하는 GetInterface()와 SetInterface()를 제공할 것이다.
각각의 설정 내에 각 인터페이스들은 인터페이스 번호와 여러 가지 셋팅들을 정의해 놓은 필드들을 가지고 있다.
디바이스가 초기 설정될 때 기본 셋팅은 셋팅 0 이다.
관련 USB 디바이스 그룹들을 관리하는 디바이스 드라이버에게 도움이 되기 위해 디바이스와 인터페이스들은 클래스(관련 디바이스 그룹에 할당), 서브 클래스(클래스가 서브 클래스로 나누어짐), 프로토콜 필드(호스트 소프트웨어가 디바이스와 어떻게 통신하는지)를 포함한다.
이 필드들은 디바이스가 제공하는 Function 이나 디바이스상의 Function 들과 통신하는 프로토콜을 식별하는데 사용된다.
4. 데이터 전송
USB 디바이스와 호스트 사이의 데이터의 전송을 나타낸다.
이전에 언급하였지만 데이터의 전송은 4가지의 전송 모드를 가진다.
Endpoint 의 번호는 다른 셋팅에서 다른 형태의 데이터의 전송을 위해서 사용될 수 있다.
그러나, 다른 셋팅이 선택되면 USB 디바이스 Endpoint 는 다른 셋팅이 선택될 때까지 오직 하나의 데이터 전송방법이 사용된다.
5. 파워 관리
파워를 관리하는 데에는 다음과 같은 두 가지의 경우가 존재한다.
5-1. 파워의 효율적인 운영
USB 의 버스에서 제공할 수 있는 파워는 한정되어 있으며, 디바이스가 Enumeration 되는 동안에, 호스트는 디바이스의 파워의 필요사항을 살펴본다.
디바이스는 1 Load Unit 또는 그보다 적은 양으로 파워의 소비를 한정시킨다.
그렇지만, 디바이스가 결합되는 포트의 파워의 능력에 따라서 USB 디바이스는 설정 이후에 5 Load Unit 까지 확장될 수 있게 된다.
5-2. 원격 Wake-up
Suspend 된 USB 디바이스가 Suspend 상태의 호스트에게 Wake up 신호를 보내 버스의 동작을 수행하도록 한다.
이는 호스트에게 Suspend 모드로부터 Resume 을 수행해야 한다는 것을 알리며, 호스트에 신호를 전달하기 위해 Suspend 상태에 있는 USB 디바이스를 트리거하기 위한 외부 이벤트를 서비스하게 된다.
6. 요청 처리
호스트가 비교적 오랜 주기를 갖는 요청의 완료에 대해 오랫동안 폴링하는 걸 방지하기 위한 방법이다.
6-1. 요청 처리 타이밍
모든 디바이스들은 요청들을 시간에 의한 방법으로 다룬다.
최대의 값은 5 sec 이다.
6-2. 리셋/Resume 복구 시간
포트가 리셋/Resume 후 USB 시스템 소프트웨어는 디바이스가 데이터 전송에 응답하기 전까지 100ms의 복구 간격을 갖는다.
복구간격 중에는 데이터 전송이 무시된다.
6-3. 주소설정 처리
리셋/Resume 복구 간격 후에 디바이스가 SetAddress() 요청을 받는다면 50ms 내에 요청 처리와 상태 스테이지 요청이 완료할 수 있어야 한다.
디바이스가 0 의 길이를 가지는 상태 패킷을 보내거나 상태 스테이지 데이터 패킷에 대한 Ack 를 감지하면 상태 스테이지 요청이 성공적으로 완료된다.
상태 스테이지의 요청 완료 후 디바이스는 SetAddress() 의 복구 간격으로서 2ms를 가지며, SetAddress() 복구 간격 2ms후에 디바이스는 새로 지정된 주소를 통해 셋업 패킷을 수신할 수 있어야 한다.
6-4 표준 디바이스에 대한 요청
데이터 단계를 요구하지 않는 표준 디바이스 요청들은 디바이스가 50ms내에 요청의 완료와 상태 스테이지의 요청을 완료시킬 수 있어야 한다.
호스트로 데이터 스테이지 전송을 요구하는 표준 디바이스 요청의 경우에 요청을 받고 500ms 내에 첫 번째 데이터 패킷을 호스트에 반환해야 한다.
이전의 패킷 전송이 완료된 후 500ms 내에 차후의 패킷들을 보낼 수 있어야 한다.
마지막 데이터 패킷을 반환한 후 50ms 내에 상태 단계를 완료시켜야 한다.
디바이스로 데이터 스테이지 전송을 요하는 표준 디바이스의 요청들인 경우는 5sec 로 한정된다.
6-5 클래스에 대해서 특정한 요청
명시된 응답보다 더 신속하게 응답할 수 있어야 한다.
6-6 요청 오류
요청 오류가 발생할 경우에 불필요한 버스의 활동을 줄이기 위해 다음의 데이터 스테이지 트랜잭션때 Stall PID 가 반환된다.
===================================================
일반적 USB 디바이스의 동작
1. 동적인 결합과 제거
호스트는 결합이 감지되면 디바이스가 붙은 허브 포트를 사용가능 하도록 설정시킨다.
디바이스는 리셋되면 다음과 같은 특성을 갖는다.
기본 주소로 응답하게 되고, 디바이스는 설정되지 않으며, 디바이스는 초기에 Suspend 되어 진다.
디바이스가 제거되면 허브는 포트를 사용 불가능시키고 호스트에게 분리되었음을 알리는 통지를 보낸다.
리셋 USB 디바이스는 다음과 같은 세 가지의 특성을 살펴보도록 해야 한다.
1. 기본 USB 주소에 대해 응답
2. 설정되지 않았는지?
3. 초기에 Suspend 되지 않았는지?
디바이스가 허브로부터 제거될 때, 허브는 디바이스가 결합되고 호스트의 제거를 알리는 포트를 사용 불가능하도록 한다.
2. 주소 할당
호스트에 의해 디바이스가 리셋되고 디바이스가 결합된 허브 포트가 인에이블된 후에 호스트는 디바이스에 유일한 주소를 할당한다.
3. 설정
호스트는 디바이스의 성능을 결정하기 위해 디바이스로부터 설정 정보들을 요구한다.
하나의 설정에서 디바이스는 여러 개의 인터페이스들을 가지고 있고, 하나의 인터페이스는 디바이스의 단일 Function 또는 특성을 나타내는 Endpoint 들의 집합으로 되어 있다.
Endpoint 들의 집합과 통신하는데 사용되는 프로토콜과 각각의 Endpoint 의 목적은 공급자가 정의한 특정한 정보이다.
인터페이스는 관련 Endpoint 들의 특성과 개수를 정의하는 여러 가지의 셋팅들을 가지고 있을 수 있으며, 이런 경우 디바이스는 특정 인터페이스에 대한 현재의 교환 가능한 셋팅을 보고하고 선택하는 GetInterface()와 SetInterface()를 제공할 것이다.
각각의 설정 내에 각 인터페이스들은 인터페이스 번호와 여러 가지 셋팅들을 정의해 놓은 필드들을 가지고 있다.
디바이스가 초기 설정될 때 기본 셋팅은 셋팅 0 이다.
관련 USB 디바이스 그룹들을 관리하는 디바이스 드라이버에게 도움이 되기 위해 디바이스와 인터페이스들은 클래스(관련 디바이스 그룹에 할당), 서브 클래스(클래스가 서브 클래스로 나누어짐), 프로토콜 필드(호스트 소프트웨어가 디바이스와 어떻게 통신하는지)를 포함한다.
이 필드들은 디바이스가 제공하는 Function 이나 디바이스상의 Function 들과 통신하는 프로토콜을 식별하는데 사용된다.
4. 데이터 전송
USB 디바이스와 호스트 사이의 데이터의 전송을 나타낸다.
이전에 언급하였지만 데이터의 전송은 4가지의 전송 모드를 가진다.
Endpoint 의 번호는 다른 셋팅에서 다른 형태의 데이터의 전송을 위해서 사용될 수 있다.
그러나, 다른 셋팅이 선택되면 USB 디바이스 Endpoint 는 다른 셋팅이 선택될 때까지 오직 하나의 데이터 전송방법이 사용된다.
5. 파워 관리
파워를 관리하는 데에는 다음과 같은 두 가지의 경우가 존재한다.
5-1. 파워의 효율적인 운영
USB 의 버스에서 제공할 수 있는 파워는 한정되어 있으며, 디바이스가 Enumeration 되는 동안에, 호스트는 디바이스의 파워의 필요사항을 살펴본다.
디바이스는 1 Load Unit 또는 그보다 적은 양으로 파워의 소비를 한정시킨다.
그렇지만, 디바이스가 결합되는 포트의 파워의 능력에 따라서 USB 디바이스는 설정 이후에 5 Load Unit 까지 확장될 수 있게 된다.
5-2. 원격 Wake-up
Suspend 된 USB 디바이스가 Suspend 상태의 호스트에게 Wake up 신호를 보내 버스의 동작을 수행하도록 한다.
이는 호스트에게 Suspend 모드로부터 Resume 을 수행해야 한다는 것을 알리며, 호스트에 신호를 전달하기 위해 Suspend 상태에 있는 USB 디바이스를 트리거하기 위한 외부 이벤트를 서비스하게 된다.
6. 요청 처리
호스트가 비교적 오랜 주기를 갖는 요청의 완료에 대해 오랫동안 폴링하는 걸 방지하기 위한 방법이다.
6-1. 요청 처리 타이밍
모든 디바이스들은 요청들을 시간에 의한 방법으로 다룬다.
최대의 값은 5 sec 이다.
6-2. 리셋/Resume 복구 시간
포트가 리셋/Resume 후 USB 시스템 소프트웨어는 디바이스가 데이터 전송에 응답하기 전까지 100ms의 복구 간격을 갖는다.
복구간격 중에는 데이터 전송이 무시된다.
6-3. 주소설정 처리
리셋/Resume 복구 간격 후에 디바이스가 SetAddress() 요청을 받는다면 50ms 내에 요청 처리와 상태 스테이지 요청이 완료할 수 있어야 한다.
디바이스가 0 의 길이를 가지는 상태 패킷을 보내거나 상태 스테이지 데이터 패킷에 대한 Ack 를 감지하면 상태 스테이지 요청이 성공적으로 완료된다.
상태 스테이지의 요청 완료 후 디바이스는 SetAddress() 의 복구 간격으로서 2ms를 가지며, SetAddress() 복구 간격 2ms후에 디바이스는 새로 지정된 주소를 통해 셋업 패킷을 수신할 수 있어야 한다.
6-4 표준 디바이스에 대한 요청
데이터 단계를 요구하지 않는 표준 디바이스 요청들은 디바이스가 50ms내에 요청의 완료와 상태 스테이지의 요청을 완료시킬 수 있어야 한다.
호스트로 데이터 스테이지 전송을 요구하는 표준 디바이스 요청의 경우에 요청을 받고 500ms 내에 첫 번째 데이터 패킷을 호스트에 반환해야 한다.
이전의 패킷 전송이 완료된 후 500ms 내에 차후의 패킷들을 보낼 수 있어야 한다.
마지막 데이터 패킷을 반환한 후 50ms 내에 상태 단계를 완료시켜야 한다.
디바이스로 데이터 스테이지 전송을 요하는 표준 디바이스의 요청들인 경우는 5sec 로 한정된다.
6-5 클래스에 대해서 특정한 요청
명시된 응답보다 더 신속하게 응답할 수 있어야 한다.
6-6 요청 오류
요청 오류가 발생할 경우에 불필요한 버스의 활동을 줄이기 위해 다음의 데이터 스테이지 트랜잭션때 Stall PID 가 반환된다.
저도 usb는 잘 모르는데다, 공부한지도 몇년이 되어서....^^