질문 —
CIPC_REG_DATA_AP2CHUB에 쓴 data는 실제 물리 주소와 어떻게 연결되는가?shared memory라는 가설
cipc_write_data(CIPC_REG_DATA_AP2CHUB, tx, length)까지 도달한 뒤에는 CIPC가 사용하는 memory 영역을 찾아야 했다. 함수 이름과 구조체를 따라가며 cipc_init, cipc_map, user_pool, sram_base를 연결했다.CIPC는 AP와 CHUB가 함께 접근하는 SRAM 영역 안에 channel과 data pool을 만들고, mailbox interrupt로 상대 processor에 알리는 구조로 보였다.
초기화 경로
contexthub_probe → contexthub_chub_ipc_init → cipc_init → cipc_map / user_pool
여기서
sram_base가 실제로 어디에서 오는지 확인하려면 Device Tree까지 내려가야 했다.Device Tree
찾은 compatible string은 다음과 같았다.
samsung,exynos-nanohub
원문에서 정리한 주요 resource는 이렇다.
reg-name | 주소 | 역할 |
mailbox | 0x12A30000 | AP–CHUB mailbox |
mailbox_apm_chub | 0x12A20000 | APM–CHUB mailbox |
sram | 0x10D00000 | CHUB shared SRAM |
sram size | 0x200000 | 2 MiB |
baaw_c_chub / baaw_d_chub | DT resource | CHUB address window |
sysreg_chub | DT resource | CHUB system register |
주소가 kernel virtual address가 되는 과정
get_iomem()을 따라가면 platform_get_resource_byname()으로 Device Tree resource를 찾고, devm_ioremap_resource()로 MMIO 영역을 mapping한다.res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name); addr = devm_ioremap_resource(dev, res);
따라서
chub->sram은 Device Tree의 0x10D00000 영역을 kernel이 접근할 수 있도록 mapping한 주소가 된다.발표자료에서 정리한 CIPC·mailbox·Device Tree 흐름
직접 읽어 보려 했지만
/proc/iomem에서 관련 영역을 확인하고 adb shell에서 접근하려 했지만 SELinux가 활성화되어 있어 읽을 수 없었다.SElinux가 활성화가 되어 있어서 adb로는 읽을 수가 없다.
그래서 software 권한을 더 얻는 방향과, hardware를 통해 regular Odin을 쓰는 방향을 같이 검토하게 됐다. 동시에 firmware binary 자체를 분석해 CHUB 안쪽에서 ODR가 설정되는 위치를 찾기 시작했다.