M SHELL for TCRP 도 ARPL 의 EUDEV 모듈(드라이버) 자동처리가 가능해졌습니다.
ARPL 의 가장 핵심 기능이라고 할 수 있는 통합모듈팩 (ARPL MODULES) 을 /lib/modules 에 복사해두고
각종 장치를 동적으로 자동인식해서 모듈주입까지 처리가 되는 기능이 있습니다.
이 기능의 중심에는 EUDEV 라는것이 있는데요.
EUDEV 란 아래와 같은 내용입니다.
TCRP 에도 이 EUDEV 를 적용하고 싶었는데, 개념부터가 정립이 안된상태에서
선뜻 M SHELL for TCRP 에 까지 적용하는것이 어려웠습니다.
pocopico님이 시작은 작년 8월부터 였지만 사용할 수 있는 레벨의 완성을 3주전쯤
TCRP 를 위해서 이 EUDEV 를 ARPL 버전에서 TCRP 용으로 포팅해 두신것 같습니다.
https://github.com/pocopico/rp-ext/tree/main/eudev
EUDEV 데몬이 실행이 되지 않는 약간의 버그가 있었지만, 원인을 해결해서 정상동작되도록 수정했습니다.
지금까지 제가 M SHELL 에 적용한 방법은 ARPL 의 통합모듈팩을 TCRP 가 디바이스 자동검색에 사용하는 방식인
lspci 커맨드로 분석된 VID / PID 기준으로
미리 준비된 modules.alias.4.json 파일을 대조해서 매칭되는 모듈을 하나씩 주입하는 방식입니다.
이렇게 정적으로 처리를 하게되면 통합모듈팩에는 준비되어 있더라도 modules.alias.4.json 가 대비되어 있지 않으면
모듈설치를 못하게 되는 맹점이 있습니다.
그 반대의 경우도 존재할 수 있겠죠?
두 개발자가 서로 다르기 때문에 충분히 두 군데에서 누락이 있을 가능성이 있었습니다.
이제 이 정적으로 modules.alias.4.json 파일을 참조하는 방식을 벗어나서 완전히 EUDEV 만으로
TCRP 에서도 ARPL 처럼 동적으로 모듈처리가 가능해 졌습니다.
ARPL 의 통함모듈리스트 파일인 모듈.ko 파일이 아래 경로등에 각 플랫폼별로 존재하고 EUDEV 가 정상적으로 장치를 검출하는한
누락되는 드라이버 없이 모든 장치가 로딩된다고 보시면 됩니다.
https://github.com/fbelavenuto/arpl-modules
이 방식을 사용하시기 위해서는 M SHELL for TCRP 로 로더를 다시 빌드해 주셔야 합니다.
M SHELL for TCRP 도 금일로서 모듈 로딩방식에 새로운 국면을 맞이하여 저로서도 뜻깊은 전환이라고 생각합니다.
새로운 버전을 적용해서 사용하시면서 버그 사항이나 개선사항은 언제든지 말씀 주십시요.
https://github.com/PeterSuh-Q3/tcrp-modules
화정큐삼
1등 지금 8개 플랫폼별로 VMWARE FUSION 과 인텔 4세대 네이티브로 EUDEV 안정성 시험중입니다.
3개정도 플랫폼 진행중인데, 무난히 잘 도는것 같습니다.
특이할만한 사항은 리얼텍 USB 랜카드에 대한 특별 패치가 적용되고 있어서
이 랜카드가 내장랜 없이도 USB 랜만으로 로더빌드부터 DSM 설치완료까지 진행하는데 도움이 되지 않을까 싶습니다.
저는 IPtime U1G 밖에 없어서 이것 밖에는 시험을 못드리는데요.
참고하셨으면 좋겠습니다.
DVA3221 덴버톤은 네이티브에서 랜이 동작하지 않는것 같습니다.
VM 은 잘되는데, 덴버톤 특성인지 시리얼 로그로 확인하기 힘들게 만들어 둔것 같습니다.
일단 두개 플랫폼은 안정화 시험 끝날때까지 로더 다시 빌드하지 마시기 바랍니다.
네이티브로 dva3221사용중인데 클날뻔했네요. 좀더 기다려야겟네요. 매번 감사합니다.
dva3219도 안될듯하네요
제가 7세대까지만 시험해 봤는데, 6세대 노트북에 한번 해보고 말씀드리겠습니다.
6,5,4 세대 노트북으로 DVA3221 TCRP FRIEND 로 시험해 봤습니다.
정확히 6,5세대까지만 동작합니다.
지금까지 4세대가 TCRP Jot 나 Friend 에서 성공하셨던 케이스가 안보이던데요.
혹시 지금 그렇게 사용하고 계시는분이 계신지 모르겠습니다.
ARPL 이나 과거 TCRP Jun 모드 (둘다 Jun 방식) 에서는 4세대 하스웰의 성공사례가 있습니다.
FRIEND 만 시험했는데, 마지막으로 TCRP jot 로더로 만든 USB로 마지막 시험 해보겠습니다.
DVA3221 (덴버톤) TCRP 에서는 5세대부터만 지원해야 할것 같습니다.
헤놀포럼의 성공사례를 찾아봤는데, DVA3221은 전부 ARPL 만 사용하시더군요.
DVA3221 / 네이티브는 인텔 7세대 이상 (아마도 6세대도 가능) 부터는 잘 동작하고 있습니다. 잘되던 하스웰에서 안되고 있는 상황은 좀더 확인해 보겠습니다.
j1900도 되는데 몇세대인지는 모르겟네요.
DVA3221 4세대 시험을 좀더 해봤습니다.
proxmox 날려먹은뒤로 vmware 에서만 시험해 봤는데,
오늘 다시 설치했습니다.
proxmox 는 CPU 종류를 kvm64 로 고정할 수 밖에 없는 특성떄문에 CPU 세대를 딱히 타는것 같지않고 모호한 부분이 있네요.
덕분에 명령어 구분하는 flags 탐지도 예외로 둘 수 밖에 없어서 그냥 전체 모델을 다 풀어서 빌드 가능하게 열었습니다.
DVA3221 덴버톤도 문제 없이 동작되는군요.
Esxi 에서는 예전 오리지널 TCRP 방식대로 eudev 를 사용하지 않는 정적매핑방식의 로더가 그대로 남아 있어서 실행해 봤더니 말씀대로 TCRP 프렌즈까지 잘 동작했습니다.
하지만 새 로더방식으로 다시 컴파일하니 eudev 때문인지 중간에 멈춰버렸습니다. 커널패닉인지 어떤지도 로그가 멈춰버려서 판단이 안되는 상황이구요.
네이티브도 같은 상황같습니다. 예전 방식이라면 동작할것 같습니다.
덴버톤 플랫폼 하나때문에 eudev 를 사용하지 않는 예외를 만들어야 하는지는 좀 생각해 보곘습니다.
대신 이 덴버톤 플랫폼만 기존 정적방식 + EUDEV 동적방식이 모두 동작되는 하이브리드로 했습니다.
기존방식이 꼭 필요한 하스웰은 정적방식 때문에 기동이 가능하게 되었고
나머지 5세대 부터는 기존 정적방식 + EUDEV 가 모두 동작합니다.
DSM설치 이후에는 데몬형태로 떠 있는 EUDEV 만 동작하는 셈이 됩니다.
EUDEV 도 정상동작 확인했습니다.
ASROCK E3C222D4U 하스웰 웍스보드가 듀얼랜인데, MAC 으로 IP 고정할당한것이 두 포트중에 왔다갔다
해서 잠시 속았습니다.
두개 포트 모두 꽂아주고 IPMI는 제외하고 모니터링 했더니 두 IP 중 최소 1개는 잡혀서 PING 이 갑니다.
제 하스웰 보드의 경우는 네이티브 EUDEV 도 정상 동작 확인했습니다.
기존 TCRP에서 기본적으로 리얼텍 랜이없어서 인식을 못하더라구요 ㅠ.ㅠ
cmt alert
신고
"님의 댓글"
이 댓글을 신고하시겠습니까?
