dm355 redundant boot loader

 

 

 

 

 

 

 

 

보드 디버깅 중 하드웨어 엔지니어 분꼐 청천벽력같은 소리를 들었었는데,

앞으로 출시될 제품에는 보드 사이즈 문제로 JTAG pin을 뽑기 어려울 것 같다고 해서..

참으로 난감해 하고 있었다.

ubl을 포함한 boot loader를 플래쉬 메모리에 퓨징하는 것은 그냥

evm 보드를 활용하면 되지만, 

혹시 나중에 boot-loader의 업데이트가 필요해서 수정하고 올렸는데

부트로더가 맛이 간다면?

플래쉬를 띄었다가 붙이는 방법외엔 다른 묘안이 없다.

또한 알수 없는 ..신도 알수 없을정도의 아리까리한 문제로 부트로더가 날아갔을 경우 정말 미치고 팔짝

뛸 수 밖에 없게 된다. 이럴 경우를 대비해서 리던던트한 부트로더를 구성했다

1. 기존 부트로더 메모리 맵

UBL과 UBoot magic number는 해당 위치에 magic number와는 다른 값이 쓰여 있으면 폭주 및 오동작 방지를 위해

부트로더 및 UBL을 로딩 하지 않게 하기 위한 일종의 방지 장치 역할을 한다.

기존 구조는 ubl 과 uboot가 메모리에 넓게(?) 산재 되어 있었는데, 이부분을 꽉꽉 밟아 쓰도록 우선 맵을 조정햇다.

2. 변경 된 부트 로더 맵

주요 변경 지점은 0x8000번지에 비상용 uboot 를 집어 넣은 부분입니다. 비상용 uboot는 magic number와 parameter는 기존 u-boot 와 공유하고 단지 실수 또는 예상치 못한 일로 u-boot (0x2c000~0x4b000) 영역이 삭제 되었을 때를 대비하여 부팅 가능하도록 하는 역할입니다.

3. 비상 부트 로더 로딩을 가능하도록 코드 수정

비상 부트로더가 자동으로 동작한다면 좋겠지만, u-boot magic number가 멀쩡할 경우에는 기존 부트로더는 멀쩡하다고 봐야한다. 이렇듯 판단 기준이 모호하므로, 자동 동작에는 어느정도 한계가 있고 동작을 하기 위해서는 input 용도의 gpio를 별도로 할당하여 해당 gpio가 low 냐 high냐에 따라 emergency 를 로드 할 것인지 기존 부트 로더를 로드할 것인지를 결정한다.

4. 앞으로 시간이 남으면

추가적으로 시간이 남으면  UBL/UBL-magic num/U-boot magic num도 리던던시하게 구성하여..좀더 효율적으로 구성하면 좋으나 귀찮은 관계로...