레이블이 DVR인 게시물을 표시합니다. 모든 게시물 표시
레이블이 DVR인 게시물을 표시합니다. 모든 게시물 표시

2024년 10월 3일 목요일

CIF 480 Embedded DVR 개발기

우여 곡절 끝에 X86으로 DVR을 완성하고 한숨 돌렸을 때였다.

개발 하고 나서 보면 반성할 점도 많고 후회되는 부분도 많은 제품이었다.

다행인건 , 그렇게 해서라도 잘 동작은 해줬다는 것이었다.


시간이 지나고 새로운 DVR 개발에 대한 요청이 들어왔다.

기간은 6개월,  당시 TOP3 안에 드는 보안업체에 주력 납품될 H.264 코덱 지원하는 DVR개발이었다.

성능은 CIF480 FPS, 당시 그 정도 성능을  내는 저가형 Embedded 제품은 없다고 봐야 하는 것과 마찬가지였다. 아직  hisilicon 칩이 라인업과 성능이 애매하던 시절이었다.


가능성을 조사를 하기 위한 한달의 여유를 경영진에 요청하였다.

일단 코덱의 경우 이전 제품을 만들면서 Softlogic 사와 좋은 관계를 유지하게 되어 , 신형 H.264 코덱에 대한 정보를 받을 수 있었다.

Softlogic사의 코덱인 Solo6110이 새로 출시 될 예정이었고, 압축, 재생 성능과 비디오 출력 기능이 있어 코덱 + 비디오, OSD  기능을 한번에 해결할 수 있었다.

다음은 SOC였다. (메인 CPU)

Solo6110 개발용 EVK 에 장착된 SOC는 프리스케일사의 Power PC 계열의 SOC였다.

이것으로 개발하면 초기 개발은 비교적 쉬워지겠지만 몇 가지 이유가 마음에 걸려 다른 SOC를 찾기로 했다.

일단, 가격이 비싸다. 당시 해당 SOC는 20$ ~ 30$ 가량 하던 SOC로 목표 금액인 200$ 에 맞추기 위해서는 SOC가 차지하는 비중이 너무 컷고, 칩이 크다보니 주변 구성 칩들도 가격이 적지 않았다.

그리고 Big-endian 이었다. 나는 PC 친화적인 방향으로 하여 개발 편의성과 PC 와 연동을 쉽게 하는 것을 목표로 삼고 있었기 때문에, Little-Endian 을 선호하였다.

SOC를 선정하기 위해 아래와 같은 조건의 SOC를 팀원들과 함께 찾아보았다.

1. 가격이 15$ 이하일것

2. Little endian 일것

3. PCI bus 필수 지원 (Solo6110 코덱이 PCI BUS)

4. SATA 지원 (하드디스크 지원 및 백업용 ODD 지원)


마음에 쏙 드는 칩은 없었고, 지금도 그렇지만 문서상 사양과 실제 사용 가능한 사양이 일치하지 않는 경우도 많았다.

여러 칩 벤더의 영업분들과 미팅을 하였고, Cortina 사의 DS3516으로 결정하였다.

칩 사양은 아래와 같았다.

CPU: ARM9TDMI

clock: 200Mhz

RAM TYPE: SDRAM

PCI BUS: 있음

USB : 2.0

SATA : 3G (2gen)

가격 : 8$

Power PC에 비하면 매우 부족한 CPU 성능이었지만, 다른 부가 기능들이 충분히 만족하였으므로, 부족한 CPU성능을 최적화로 극복해 보기로 했다.


부족한 성능을 극복하기 위하여 이번에도 Solo6110의 드라이버를 직접 개발하기로 했다.

DVR의 제일 많이 사용하는 데이터 전송인 압축된 데이터 전송, OSD 출력에 CPU 의존성을 최대한 낮추기 위하여 PCI BUS MASTER DMA를 최대한 활용해야만 했다.

덕분에 DVR의 엔진과도 같은 상당한 기능을 Solo6110 드라이버에서 담당하게 되었다.

덩치 큰 드라이버 개발도 쉽지 않았지만, 생각보다 CPU의 제약 사항도 많았다.

ARM9TDMI 의 성능 한계 상 나눗셈 연산이 매우 느렸고, unaligned memory access 를 지원하지 않아, 데이터를 읽을 때에는 반드시 변수 크기의 배수 주소에서 읽어야만 했다.

무슨 뜻이냐면, 32bit int 형 변수를 읽으려면 32bit는 4byte 이므로 4의 배수 포인터에 있는 변수만 읽을 수 있고, 4의 배수가 아닐 경우 읽은 값이 깨져서 들어오거나 일부 CPU는 unaligned exception error 가 발생한다.

평소에는 컴파일러가 변수 크기에 맞춰 주소 정렬을 해주어 상관 없지만, 통신 등으로 binary 데이터를 분석 할 때에는 정렬이 되어있지 않는 경우를 대비하여 정렬된 주소에 한 바이트 씩 복사한 후 값을 읽어야 한다.

우여곡절 끝에 기본 기능을 완성하고 백업을 위한 ODD(광학 드라이브, CD라이터나 DVD라이터)를 연결할 차례가 되었다.

여기서 한번 뒤통수를 맞게 된다. SATA포트에 장착한 DVD Writer 가 동작하지 않는 것이었다.

확인 결과, DS3516은 분명 SATA를 지원하지만, 프로토콜을 하드디스크를 위한 ATA 만 지원하고, ODD 드라이브를 위한 ATAPI를 지원하지 않는 것이었다. 

이미 샘플보드를 만든 상황에서 급하게 비상 회의를 열고, PCI 버스를 확장하여 SATA컨트롤러인 sil3512를 추가하기로 한 것이다.

긴급으로 칩을 수배하여 수정된 보드에 다시 DVD Writer를 작동 시켰다.

이번에는 데이터가 깨지기 시작하는 것이었다.

확인 결과 DS3516는 PCI 의 burst 전송이 512 byte 이상 되면 데이터가 깨지는 현상이 발생하는 문제가 있었던 것이었다.

두 번째 난관은 비교적 평온하게 해결했다. 저가형 CPU다 보니 워낙 난관이 많았다 보니, 하드웨어 수정이 아닌 펌웨어나 소프트웨어 수정 작업은 그리 크게 느껴지지 않은 것이었다.

결국 DVD Write 하는 펌웨어, 소프트웨어도 직접 개발하여 PCI burst 를 512byte까지만 사용하도록 제약을 하였고, 직접 개발하게 되었으니 여기 서도 CPU를 최대한 쓰지 않게 하기 위하여 일반적인 DVD 백업처럼 iso 이미지 파일을 만든 후, 전송하여 굽는 방식이 아닌, 실시간으로 생성하여 iso 이미지를 저장할 공간 확보를 할 필요가 없도록 만들어, 백업 시간을 대폭 줄였다.

느린 CPU로 이것이 가능 한 이유는 DVD-writer들이 buffer under-run 방지 기술이 적용되어서 타이망의 제약을 받지 않아서 이기도 했다.

전화위복이라 하였던가, DVD-write 기능 직접 개발로 인해, 힘은 들었지만, 개발된 제품은 DVD backup이 타 제품보다 빠른 제품으로 인정받게 되었다.


중간에 예상치 못한 문제로 개발 기간도 2개월 가량 추가 되었고, sil3512 관련 부품이 추가되어 원가가 조금 오르긴 했지만, 목표했던 200$보다 저렴한 제품을 만들 수 있게 되었다.

다행히도 제품은 성공적으로 개발되어 보안회사에 무사히 납품할 수 있게 되었다.


2024년 10월 1일 화요일

x86계열 스텐드 얼론 DVR 개발기

 2007년 개발 기안으로 나는 고급형 스텐드 얼론 DVR을 제안하였다.

사양은 당시로선 고급 사양인 CIF 해상도에 480프레임이 지원되는 DVR이었다.

코덱 칩은 소프트로직(SOFT LOGIC)사에서 개발한 SOLO라는 칩이 있었는데 목표사양에 적합했다. 하지만 문제가 있었는데, encoding은 되지만 decoding이 안되는 것이었다.

이를 해결하려면 decoding은 CPU (SOC)에서 해야 했다.

지금은 PC사양이 높아지고, 비디오 카드와 CPU에도 영상 관련 가속기능들이 생겨 큰 문제는 아니지만, 당시에는 MPEG4로 압축된 영상을 CIF 480 디코딩을 한다는 것은 PC에서도 쉽지 않은 일이었다.

몇몇 SOC 업체들과 미팅을 하다 눈에 들어오는 SOC를 발견하였다.

AMD geode LX800이다.

이 SOC는 다음과 같은 이점이 있었다.

  • 500Mhz 의 높은 성능

  • MMX 지원으로 영상 처리 일부 가속 가능

  • x86계열로 크로스 컴파일 불필요

SOC와 코덱을 선정한 후 개발 기안을 품의 받아 개발에 착수 하였다.

생각치 못한 첫번째 난관이 도래했다.

바로 BIOS다.

내가 x86을 우습게 생각했었다.

x86CPU니까 바로 보드를 찍어 리눅스를 설치하면 될 것이라 생각했는데, x86의 주변기기 자원을 리눅스로 전달 할 수 있는 BIOS가 필요한 것이었다.

당시 리눅스를 바로 돌릴만한 x86용 부트로더는 찾을 수 없었고

LX800에 기본 내장 된 기능들은 방대하였다.

X86의 특징중 하나인 시작시 16bit real mode로 시작하여 단계적으로 32bit protected paging 모드로 진입해야 한다는 것도 x86에서 부트로더를 개발하는데 저항감을 주는 원인중 하나인 것 같다.

불행 중 다행은 8086 시절 BIOS는 어셈블리 레벨로 어느 정도 파악을 하고 있었고, 32bit 초기시절 OS개발 프로젝트에 참여하였기 때문에 어느정도 지식이 있다는 점이었다.

이후 미친듯이 AT BIOS와 PCI bus 리소스관련 자료를 찾아 공부하였다.

AT BIOS 소스의 경우 예비군 훈련장까지 가지고 가서 볼정도로 발등에 불이 떨어져 있었다.

활용 가능한 opensource의 bios가 있는가도 찾아보았는데, 다행히도 open bios라고 제한적인 기능이지만 LX800의 레거시 장치의 자원을 지원하는 bios를 찾을 수 있었다.

드디어 BIOS 1차버전이 완성되고 주변 장치 정보를 LINUX에 잘 전달하는지 확인하였다.

부팅된다! 만세가 터져나왔다.

그런데 이상하다.

내장 peripheral 장치들은 잡히는데 중요한 PCI bus에 장착된 SOLO 코덱칩이 잡히지 않았다.

내가 사용한 open bios는 내장된 장치에 대한 부분은 있었지만 PCI bus에 대한 장치 탬색 및 열거 (enumeration)이 되지 않았다.

LX 800의 데이터시트를 보며 이 부분을 추가적으로 구현하였고, SOLO에서도 이와 관련 된 부분에 호환이 되지 않는 부분을 발견하여 SOLO의 VID와 PID를 발견하면 예외처리를 추가하여 장치 자원을 잡도록 하여 성공하였다.

이 후에도 생각보다 LX800의 소프트웨어 디코딩 성능이 안나와 패닉에 빠졌었지만, 다행히도 SOLO에 디코딩 통합형 버전이 나온다 하여 위기를 넘길 수 있었다.

무척이나 급했기 때문에 SOLO 칩은 드라이버 마저 완성되지 않았지만, 칩업체에 설득하여 데이터시트를 받아 (데이터 시트도 완성되지 않은 상태였다) 드라이버를 직접 개발하여 사용했다.

이 후 인연이 되어 SOLO 코덱 칩은 Hisilicon으로 넘어가기 전까지 계속 사용하였고, 드라이버는 자체 개발버전을 사용하였다.

여러 고비를 넘기고 제품이 완성되었지만 고급형 제품이 그렇듯 그렇게 많이 팔리진 않았다. 오히려 다음 프로젝트로 개발한 저가 ARM SOC로 개발한 저가형 H.264 DVR이 ADT에 납품 되는 등 많이 팔리게 되었다.

역시 고급형은 만드는 보람은 있지만, 매출은 저가형으로 올리는 것인가 보다.

x86계열 SOC는 이후로는 사용하지 않았고 앞으로도 그럴 것 같다.

이유를 정리해 보면

  • BIOS 개발이 힘들다. 저때는 legacy 타입으로 개발했지만 요즘은 UEFI 타입으로 개발해야 한다.

  • DVR이나 NVR로 쓰기에는 가성비가 좋지 않다. (가성비 좋은 칩들이 많아 나왔다)

  • 메인보드 개발이 힘들다. 성능이 앞서는 만큼 PCB 수준도 높게 요구하고, SMT 역시 쉽지 않았다. 하드웨어 담당자와 PCB 제조사 사장님들과 SMT 사장님들께서 고생이 많으셨다.

상세하게 적지 않았지만, 제조원가 절감을 위해서 치뤄야 할 고생이 매우 큰 제품이이었다.

나름 좋은 경험이었지만, 혹시라도 x86으로 임베디드 장비를 만들어야 할 상황이 온다면 산업용 메인보드를 구매하여 사용하라고 권장하고 싶다.