허허허...RTOS는 원래 이런가요 -ㅁ-;;;;
글쓴이: kalstein / 작성시간: 수, 2007/11/21 - 8:24오후
TI DSP 개발을 하고있는데...내부램 1MB는 참 작더라구요...
지금 소스코드들은 외부램을 직접 구역 정해서 쓰고있구요...
L2 cache 관련된 문서들도 있고 그래서...
'오호...쪼끄만 OS주제에...L2 cache 관리도 하고...나름 기특한걸~ 공부해봐야지'
뭐 첫부분은...캐쉬를 왜 쓰나, 쓰면 좋은점, L1, L2 cache 설명....
그러나....이뭐병;;;
Whenever external memory caching is enabled and the EDMA is used to transfer to/from external memory, it is your responsibility to maintain cache coherence. Failing to do so almost certainly results in incorrect functioning of the application.
두둥....
캐쉬관리자를 짜야된다는 말씀........................
것도 잘 짜야된다는 말씀........;;;
더불어 DMA연동되는 부분도 죄다 다 짜야된다..라.
아놔;;; OS라는 이름이 무색합니다...MMU도 없고...
그냥 기존방식대로 가야할것 같습니다 ㅠ.ㅠ 아흑
Forums:
어떤 OS를
어떤 OS를 사용하시나요 ?
저는 VxWorks에서 작업하고 있는데., RAM이 1G나 됩니다 ㅡㅡ;
-----------------------------
in the real-time scheduler !
BIOS라고...(바이
BIOS라고...(바이 오에스 라고 읽더군요...)
TI 에서 제공하는 OS를 사용중입니다만...좀 OS라고 보긴 민망한것 같아요;;;
상당히 많은 부분을 RAW하게 접근한다는;;;
OS에서는 대충...task들 스케쥴링이랑 semaphore 같은거 관리...그정도만 하는듯;;
1G 램 환경...부럽습니다 ㅠ.ㅠ 전 이런 답답한 환경 안좋아하는데;;
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
BIOS 자체가 DSP용으로
BIOS 자체가 DSP용으로 만든 매우 간단한 OS라서 그렇습니다.
전통적으로 DSP 프로그래밍에서는 firmware 프로그래밍만 하지 OS 자체를 사용하지 않죠.
이제는 DSP 프로그래밍도 복잡해져서 firmware 프로그래밍 모델로써는 감당하기 힘든 부분이 많이 발생하게 되었습니다.
때문에 firmware를 대체할 목적으로 매우 간단하고 단순하게 만든겁니다.
어찌보면 TI에서 OS를 제공해준것도 나름 신경쓴겁니다.
PS. 다 그런건 아니고 BIOS가 DSP용 RTOS라서 그런 겁니다.
TI DSP/BIOS 상당히 괜찮은 OS입니다만...
L2 cache 부분을 관리하는 코드를 짤 필요는 없구요, 몇가지 configuration만 해주면 됩니다.
L2 cache를 internal ram으로 쓸 부분과 cache로 쓸 부분으로 나눠주고 (몇가지 예가 있습니다)
, 그 다음 cache로 쓰겠다면 memory의 어떤 부분을 대상으로 cache할 것인지 masking해주면 됩니다.
internal ram으로 쓰겠다면 변수나 함수 생성시에 컴파일러 지시자 써서 section을 지정해 줄 수 있습니다. 외부 메모리가 아니기 때문에 속도가 엄청나죠.
제가 알기로 cache 관리는 영역 설정과 masking이 거의 다입니다. 별도 프로그램은 당연히 없지요.
DMA는 EDMA configuration 해서 써주면 되구요.
CSL(chip support library)을 사용해서 설정해도 되지만 DSP/BIOS configuration tool을 사용하면 아주 간단하게 사용할 수 있습니다.
DSP/BIOS가 무식해보여도 실제 사용하다 보면 단순해서 더 알기쉽습니다. 특히 CSL이나 BSL은 정말 일관성있게 잘 정리되어 있다는...
저의 경우는 오히려 리눅스가 너무 복잡하고 비대하다는 느낌을 많이 받습니다.
단순히 세팅만 하면 되지는 않던데요...
BIOS에서 L2 cache 모드를 쓰겠다는 취지 자체가...큰 메모리가 필요하다는 뜻이고...이는 즉 DMA를 사용해야 됨을 의미하는데요... CPU에서 직접 접근하는 경우에야 L2 cache 설정만 하면 장땡인거 같습니다만...그게 아니라 부가장치들(McBSP, DMA, external device...etc. 페리페럴이라고들 하죠. 스펠이 기억안나서 한글로 써놓습니다 ^^;) 이 외부 메모리를 access하는 경우에는 동기화 작업을 개발자가 직.접. 해줘야합니다 ㅡ.ㅡ;;;;
즉...간단히 말해서...L2 cache 사용시, 메모리 사용의 위치투명성을 제공하지 못한다고 볼 수 있죠...
그렇다면 개발자 입장에서 생각해야하는 부분이 한단계 더 늘어나게 되고, 그만큼 시스템의 버그 발생 가능성을 높인다고 생각합니다. (컴퓨터공학자인 제 입장에 봤을때...엄청난 전역변수, extern 등으로 점철된 현 소스코드도 이미 충분히 유지보수성을 생각치 않은 부분이 보이는데...저것까지 추가되었을땐 끔찍할것 같더군요. 뭐...신입입장에서 어케 뜯어 고치진못하고 있습니다만...)
그렇다고 external SDRAM을 CPU로 직접 access할순 또 없는 노릇이구요...(워낙 느리니까 ㅡ,.ㅡ;)
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
페리페럴 엑세스 시에 cache를 사용한다는게 잘 이해가 가지 않습니다만...
페리페럴 컨트롤 하는 디바이스 드라이버들은 cache를 쓰는 경우가 없는데, 잘 이해가 안가는군요. 오히려 uncachable하게 세팅해야 맞습니다만... 페리페럴들이야 대부분 데이터 FIFO를 사용하게 되는데 이걸 cache로 다룰 순 없죠.
DMA 동기화 작업은 개발자가 직접 해주는 것이 맞긴 맞습니다.
하지만 이건 DSP/BIOS만 그런 것이 아니라 어떤 OS 든 마찬가지 아닌가요?
리눅스라고 디바이스 드라이버에서 DMA 시작과 끝 세팅안하고, DMA done interrupt check안하고 드라이버 짤 수 있는 방법이 있습니까?
L2 cache를 개발자가 직접 컨트롤 한다면 어디에 어떤 부분을 건드려서 직접 구현하겠다는 것인지 모르겠네요.