TL;DR
- Linux용 Quartus의
jtagd에서 USB 데이터 손상과 첫 JTAG 작업의 약 30초 지연을 일으키는 버그 두 건이 확인됐으며, 패치 도구로 USB Blaster 복제품의 문제를 해결할 수 있음. - 첫 번째 버그는
JTAG_SERVER_USB_BLASTER생성자의 초기화되지 않은 변수 때문에 USB-Blaster II용 데이터가 구형 USB Blaster 프로토콜에 삽입되는 문제임. - USB 장치를 분리했다가 다시 연결하고
jtagd를 계속 실행하는 경우, 새 객체 생성과 힙 메모리 재사용으로 첫 번째 버그가 나타날 수 있음. - 두 번째 버그는 FT245에 명령을 보내는 순서와 일부 복제품의 반응이 맞물려 발생하며, Set Latency Timer를 먼저 보내면 문제가 사라짐.
- 두 버그는 Quartus 18.1부터 25.1까지 남아 있으며, 패치 적용과 이전 펌웨어·CPLD 수정으로 보유한 복제품 전체에서 스트레스 테스트를 통과함.
Linux의 간헐적 USB Blaster 문제
- 몇 년 전 Altera USB Blaster 복제품 문제를 조사하던 중 Linux의
jtagd에서 간헐적으로 발생하는 문제를 발견했으나, 당시에는 원인을 찾지 못함. - Quartus Programmer 18.1을 Linux에서 시험하던 컴퓨터에서는 FT245나 CPLD가 관여하기도 전에 Wireshark 캡처에서 USB 송신 데이터 손상이 나타남. 이 문제는 CPLD와 FT245를 조합한 장치뿐 아니라 모든 USB Blaster에 영향을 줌.
- CPLD 기반 USB Blaster를 연결한 뒤 Linux에서 처음 JTAG 작업을 시도할 때 약 30초 지연이 간혹 발생함.
jtagd가 도착하지 않는 바이트를 기다리다 시간 초과 후 재시도하는 것으로 보이며, 이후에는 정상 작동함. - 다른 USB Blaster 문제를 다루느라 이 두 문제의 추가 조사는 중단했으나, 인공지능(AI)을 이용해 조사 시간을 크게 들이지 않고도 원인을 밝힐 수 있었음.
Claude Opus 5.5의 역공학과 패치 도구
- 두 문제를
Claude Opus 5.5에 입력하자jtagd역공학을 통해 각각의 원인을 찾아냄. - 첫 번째 버그 조사와 시험 중 사이버 안전장치에 걸리는 상황이 있었지만,
Opus 5.5는 다른 접근을 시도하거나 프롬프트를 다시 작성할 기회를 제공하는 등 이전 버전보다 유연하게 대응함. 이전 버전에서는 안전장치가 작동하면 곧바로Opus 4.8로 전환되고, 비슷한 제한에 다시 걸리면 세션이 끝날 수도 있었음. - 버그를 수정하는 데 사용할 수 있는 패치 도구는 다음 링크에서 제공됨.
- Altera Linux jtagd 수정 도구
첫 번째 버그: 초기화되지 않은 변수와 USB 데이터 손상
- USB 트래픽 손상의 원인은
JTAG_SERVER_USB_BLASTER생성자에서 초기화하지 않은 변수 하나임. 생성자는 주변의 여러 변수를 0으로 설정하지만 이 변수는 빠져 있음. - 변수 값이 0보다 크면 Altera의 신형 USB-Blaster II 전용 데이터가 송신 USB 데이터에 추가됨. 구형 USB Blaster는 이를 처리하지 못하며, 원래 USB Blaster 프로토콜을 사용하는 복제품도 모두 영향을 받음.
- 그 결과 약 30초 동안 멈춘 뒤
Unable to read device chain - JTAG chain broken오류가 발생함. USB 데이터 손상이 신형 USB Blaster 프로토콜용 데이터 삽입 때문이라는 연결은 역공학을 통해 드러남. - 이 문제는
jtagd를 계속 실행한 채 USB Blaster를 분리했다가 다시 연결할 때만 나타나는 것으로 보임. 첫 메모리 할당은 대체로 0으로 초기화되지만, 핫플러그할 때마다 새JTAG_SERVER_USB_BLASTER객체가 생성되고 힙의 일부가 재사용되기 때문임. - 2024년 당시 조사의 상당 부분은 Windows 가상 머신에서 진행됐으며, 장치를 자주 분리하고 다시 연결했을 가능성이 있음. 흔한 상황은 아닐 수 있지만 문제를 겪을 때는 매우 성가심.
두 번째 버그: FT245 명령 순서와 30초 지연
- 지연 문제는 USB Blaster에 들어간 FTDI FT245 계열 칩의 종류, 그리고 컴퓨터와 연결된 방식에 따라 달라지는 것으로 보임.
jtagd가 칩을 처음 열 때 보내는 명령 순서는 Reset → Purge TX → Purge RX → Set Latency Timer임.- 이 명령 순서 때문에 일부 복제품은 약 250밀리초 동안 수신 데이터를 무시하는 것으로 보임.
jtagd가 곧바로 연결된 JTAG 체인을 확인하려고 통신을 시작하므로 응답을 기다리다 30초 동안 멈춤. - 복제품마다 이 명령 순서에 반응하는 방식이 다르며, 일부는 영향을 받고 일부는 그렇지 않음. 칩의 개정판이 다른지는 확인되지 않았으며, 확인된 것은 FT245 명령 순서를 바꾸는 것만으로 문제가 사라진다는 점임.
- Set Latency Timer를 첫 번째로 보내면 지연이 완전히 사라짐.
수정 적용과 검증
- 두 문제는 적어도 Quartus 18.1부터 존재하며 Quartus 25.1에서도 남아 있음. 첫 번째 버그는 수정할 필요가 있으며, 두 번째 문제는 복제품 칩이 공식 장치와 다르게 동작하는 경우인지 실제 버그인지 확실하지 않음.
- 두 번째 문제에는 Set Latency Timer 뒤에 300밀리초 지연을 넣는 방법도 해결책일 수 있음.
- 두 문제의 수정과 이전 펌웨어·CPLD 수정까지 적용한 뒤, 사용할 수 있는 USB Blaster 복제품이 모두 정상 작동함.
uhubctl과 호환되는 USB 허브로 복제품 전체의 전원을 자동으로 껐다 켜며, 수정 사항을 검증하기 위한 피드백 루프를 구성해 스트레스 테스트를 수행함.
조사 과정과 후속 계획
- 첫 번째 버그는
valgrind를 사용했다면 직접 발견할 수도 있었으며, 당시 이를 시도하지 않은 점은 아쉬움으로 남음. - 버그 재현을 위해
rr로 조사했지만 주 개발 컴퓨터와 호환되지 않았음.rr을 사용할 수 있는 구형 컴퓨터에 Quartus를 설치한 뒤에는 문제를 재현하지 못해 조사를 중단함. - 이 버그는 최소 8년간
jtagd에 남아 있었으며, Altera 포럼의 한 게시물에서 누군가 이상 동작을 알아차렸지만 거의 주목받지 못함. - 이번 글은 AI 활용 사례를 선보이는 데 그치지 않고, 커뮤니티에 유용한 우회책을 공유하고 Altera가 장기간 남아 있는 버그를 수정하도록 알리는 목적을 가짐.
- 과거 USB Blaster 조사에서 남은 마지막 질문 하나를 해결하는 후속 글도 예정돼 있음.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요