본문으로 바로가기

MultiCAS에서 VMX로 부팅한 경우는 어떤 문제도 발생하지 않지만, CNX로 부팅하면 AV 디코딩이 안되는 문제가 발생한다. Uboot에서 부트로고를 동영상으로 처리하여 바로 확인이 가능한데, CNX는 동영상이 출력되지 않는다.


Uboot 코딩을 잘못하였는지 이틀간 살펴보아도 문제는 없었다. 만약 문제가 있다면 VMX에서도 출력되지 말아야 하는데, VMX는 정상적으로 처리하기 때문에 Chipset에서 바이너리로 제공하는 모듈이 문제일 것이라고 생각하여 Chipset에 문제점을 리포팅하였지만, Chipset 레퍼런스 코드로는 문제가 발생하지 않는다고 한다.


내가 놓친것이 있나 다시 확인을 하였지만, 잘못된 부분을 찾을 수 없었다. 내가 작성한 코드이기 때문에 편견에 쌓여 안보일수 있어, 팀원과 함께 살펴보았지만 역시나 특이 사항은 발견되지 않았다.


도저히 이해가 되지 않아, Chipset의 레퍼런스 코드를 실행하여 보고, 우리 것과 확인을 해보았다. 제일 의심가는 것이 바로 메모리맵이었다. AV 디코딩을 담당하는 모듈은 SEE인데, 동일 SEE로 레퍼런스는 문제가 없고 우리 것은 문제가 있다면 메모리 맵말고는 차이가 없을 것이라고 생각하고 살펴보니 레퍼런스와 우리 것이 차이는 PIP 메모리를 설정 유무에 차이가 있었다.


PIP 메모리 설정을 추가하고 확인하여 보니, CNX도 정상적으로 AV 디코딩되는 것을 확인할 수 있었다. 리눅스에서 메모리 설정은 DTS에서 하는데, VMX의 SEE는 DTS를 참조하여 AV 관련 메모리 설정을 하는데 CNX SEE는 하드코딩된 메모리를 사용하는 것 같다.


정말 이 황당함에 당황스럽기까지 한다. SEE 모듈에서 메모리를 하드코딩된 값을 사용하는 것이 매우 황당한 일이며, 이 프로젝트가 아닌 동일 CAS를 사용하는 다른 프로젝트는 PIP를 제거하여도 이런 문제가 발생하지 않는데, 이 프로젝트에서는 왜 이런 문제가 발생하는지 이해가 되지 않는다.


어쨌든, 문제의 원인을 찾아 Chipset에게 리포팅하였으니, 수정해 줄지 기달려봐야 할 것 같다. 연속된 프로젝트라 0.9에서 사용한 SEE를 전달한 것 같은데, 고쳐줄지 모르겠다.


별것도 아닌 것에 이틀이나 소비한 것이 좀 짜증나는 일이긴 하지만, 이것 때문에 DTS를 다시 살펴보았으니, 이것으로 위안을 삼아야 될 것 같다. 연속성을 가지는 프로젝트라도 SEE에서 AV 메모리를 하드 코딩으로 참조한다는 것은 매우 위험한 것인데, Chipset에서 이것을 고쳐주면 좋을 것 같긴 한데, PIP를 사용하지 않는데 메모리 사용하는 것도 낭비이고... 암튼 기달려 보자.


덧...

Chipset에서 답변이 왔다.

CAS 규격으로 VMX는 DTS을 참조하는 것이 가능하지만, CNX는 고정된 메모리맵을 사용해야 한다고 한다.

그렇다면, 이런 내용을 사전에 알려주었으면 좋았을텐데 여전히 개발에 필요한 가이드라인에 대해서는 불만족스럽다. 우리도 개발 과정에 대한 문서화 작업이 미흡하긴 하지만...


어쨌든, Chipset에서 SEE를 다시 배포해 줄 수 있다고 하는데, PiP를 사용할 경우 약 60MB의 메모리가 사용된다 이로 인해 PiP 유무에 따라 메모리맵이 변경되어 SEE가 AV를 디코딩 못할 수 있다. 60MB의 메모리 확보하기 위해서는 PiP를 제거하는 것이 맞는데, 이것은 우리 임의대로 할 수 없어 일단 유지하도록 하였다.


추후, 사업자 요구 스펙에 따라 메모리 확보를 위해서 PiP를 적용여부를 확인하면 될 것 같다.

'개발일기 > 작업일지' 카테고리의 다른 글

VSCode 대용량 C/C++ 개발환경 설정  (0) 2019.08.16
플래시 문제점 검토  (0) 2018.01.23
아오... 이 황당함은 뭐지...  (0) 2018.01.18
부트로더, 공유 라이브러 정리  (0) 2018.01.17
VMX 포팅중... -8-  (0) 2018.01.02
VMX 포팅중... -7-  (0) 2017.12.21

댓글을 달아 주세요