리눅스가 패닉으로 빠지는 상황은 많이 있지만, 일주일이나 한달에 한번 패닉에 빠지는 경우엔 어떻게 디버깅을 해야할지 참 남감합니다.
뚫어지라고 쳐다볼 수도 없고, 머라 머라 메세지가 줄줄줄 나오는데, 뭐라고 해석을 해야할지 도통 머리가 아픈 경우가 많이 있습니다.
프로세서는 어지간하면 프로그램을 코드를 읽고, 해석하고, 계속 실행하려고 합니다. 하지만 나누기 연산을 하려고 하는데 분자 값이 '0'이면 (1/2 = 0.5, 1/4 = 0.25, ... 1/0 = inf) 프로세서는 더 이상 일 못하겠다고 한마디 비명을 지르고 예외처리 상태로 빠지게 됩니다.
이렇게 프로세서가 더 이상 일을 못하겠다고 비명을 지르는 경우가 몇가지 있는데, 앞에서 얘기한 div zero가 있고, 또 대표적인 것이 프로그램을 읽어서 해석하려고 하는데, 자기가 가지고 있는 명령어 테이블에 없는 명령어를 읽은 겁니다.
"~에이 그럴리가 있나요" 라고 얘기하면 안되요. 실제로 자주는 아니지만 아주 가끔 발생하는 경우가 있습니다. 임베디드 시스템을 사용되는 환경이 너무 춥고, 덥고, 흔들리고, 번개치고, 전기가 들어왔다 나갔다하고, 홍수가 나서 물이 차네 마네 하는 그런 험악한 공간에서는 정말 신비한 현상들이 많이 일어난답니다.
요즘 프로세서들은 이렇게 예외적인 상황이 발생했을 때, 어떤 종류의 예외상황이 발생했는지 알려주고, 정해진 예외처리 함수를 호출하고 가만히 기다립니다. 아무것도 안하고.
만약 잘못된 명령어를 만나게 되면, illegal opcode exception 함수를 호출하는데, 이 함수에서는 보통, illegal opcode를 읽은 번지와 잘못된 코드가 뭔지 알려주고 while(1); 과 함께 가만히 기다립니다.
프로그램이 왜 망가졌을까요? 누가 망가뜨렸을까요? 메모리가 불량일까요? 아니면 프로세서가 불량일까요? 아니면 메모리콘트롤러가 뭔가 바보같은 짓을 했을까요?
요즘 자일링스 MPSoC와 같은 복잡한 디바이스에는 메모리를 억세스하는 마스터가 많이 있습니다. 예를 들면 four A53, two R5, CDMA, two USB, four Ethernet, ... 아이고 힘들다.
복잡한 시스템이네요.
게다가 MPSoC는 PL (Programmable Logic)에 필요한 마스터를 설계해서 놓기 때문에(이런 마스터를 커스텀 마스터라고 합니다), 프로세서하고 커스텀 마스터와 각종 주변장치들의 마스터들이 서로 데이터를 넣고 빼겠다고 하면서, 엉키지 않게 잘 동작하긴 하죠.
그런데 말입니다. 정말 가끔 가끔 한 일주일에 한번, 한달에 한번, 1년에 한번 어떤놈이 휘~익 가닥해서 이상하게 동작하면 정말 신비한 현상이 벌어지는 거죠.
이런 일을 막을 수 있을까요? 정말 고민이 많이 됩니다.
신뢰성 있는 제품은 어느 환경에서도 정해진 절차대로 작업을 해야 하는데.
하여간 이런 현상이 벌어 질 수도 있다고 가정을 하면, 역시 어떻게 이런 동작이 생기는 것을 알아내고, 미리 대비할 수 있을까라는 고민에서 시작한 된 것이 바로 XMPU, XPPU 입니다.
XMPU (Xilinx Memory Protection Unit)는 마스터와 메모리간의 억세스영역을 정해두고 그 범위를 벗어난 억세스가 발생하면 에러를 출력하고 어떤 마스터가 어디를 억세스했는지 알아냅니다.
XPPU(Xilinx Peripheral Protection Unit)는 마스터와 주변장치간의 억세스를 영역을 정해둡니다. 즉 특정 마스터가 특정 주변장치만 억세스하도록 설정하고 그 범위를 벗어나는 역시 같은 동작을 하게 됩니다.
그외 Trust Zone과 같은 개념도 설명하고 있으니, 복잡한 시스템 (마스터가 한 10개 정도 되는 시트템)을 만드는 설계자라면, 꼭 읽어보고 적용하시기 간절히 부탁드립니다.
'support history' 카테고리의 다른 글
중국 조건부 승인 <= 자일링스와 AMD의 합병, Jan2022 (0) | 2022.01.22 |
---|---|
eTOPS가 뭐지? (0) | 2022.01.22 |
2022년 반도체 수급문제 (0) | 2022.01.22 |
왜 눈물을 흘리시나요? 캐시코히어런스 (0) | 2022.01.08 |
왜 프로세서는 주소가 없죠? (0) | 2022.01.08 |