2013-03-15 4 views
2

저는 Uboot 부트 로더 작업을하고 있습니다. Bootloader의 기능과 처리 할 응용 프로그램에 대한 기본적인 질문이 있습니다.부트 로더 작동

Q1 : 내 지식에 따라 부트 로더는 응용 프로그램을 메모리로 다운로드하는 데 사용됩니다. 인터넷을 통해 나는 부트 로더가 응용 프로그램을 RAM에 복사 한 다음 응용 프로그램을 RAM에서 실행한다는 것을 발견했습니다. Bootloader가 작동하는 것과 혼동을 느낍니다 ... 직렬 또는 TFTP를 통해 부트 로더에 응용 프로그램이 제공되면 Bootloader가 먼저 RAM에 복사할지 또는 직접 플래시에 쓰는지 여부를 결정합니다.

Q2 : 부트 로더가 응용 프로그램을 RAM으로 복사 한 다음 RAM에서 응용 프로그램을 실행해야하는 이유는 무엇입니까? FLASH에서 응용 프로그램을 실행하면 어떤 어려움을 겪게됩니까?

질문 3 : "내 응용 프로그램이 RAM/플래시에서 실행 중"이라는 문장의 의미는 무엇입니까? 응용 프로그램의 .text 세그먼트 또는 .code 세그먼트가 RAM/FLASH에 있다는 것을 의미합니까? 그리고 RAM에 있기 때문에 .bss 섹션에 관심이 없습니다.

감사 Phogat

답변

3

하드웨어 시스템을 설계 할 때 디자이너는 실행 코드의 위치를 ​​고려해야합니다. 대답은 마이크로 컨트롤러, 포함 된 메모리 유형 및 시스템 요구 사항에 따라 다릅니다. 따라서 응답은 시스템마다 다릅니다. 일부 시스템은 RAM에있는 코드를 실행합니다. 다른 시스템은 플래시에있는 코드를 실행합니다. 당신은 당신의 시스템이 무엇을 할 수 있는지 알기 위해 우리에게 충분히 말하지 않았습니다.

RAM 액세스 시간이 플래시보다 빠르기 때문에 시스템이 RAM에서 코드를 실행하도록 설계되어 코드가 더 빨리 실행될 수 있습니다. 플래시가 풍부하고 RAM이 아닐 수도 있기 때문에 플래시 코드를 실행하도록 시스템을 설계 할 수 있습니다. 플래시에서 코드를 실행하여 시스템을 더 빨리 부팅 할 수 있도록 시스템을 설계 할 수 있습니다. 이것들은 단지 몇 가지 예이며 다른 고려 사항들도 있습니다.

RAM은 휘발성이므로 전원을 껐다 켜면 코드가 유지되지 않습니다. 시스템이 RAM에있는 코드를 실행하면 부트 로더가 전원을 켤 때 코드를 RAM에 쓰고 작성해야합니다. 플래시는 비 휘발성이기 때문에 즉시 전원을 켜면 실행이 시작될 수 있으며 부트 로더는 필요하지 않습니다 (그러나 여전히 유용 할 수 있음).

Q3에 대한 대답은 '예'입니다. 시스템이 RAM에서 실행 중이면 .text는 RAM에 저장됩니다 (부트 로더가 RAM에 복사 한 후에 만 ​​가능합니다). 시스템이 플래시에서 실행 중이면 .text 섹션이 플래시에 위치합니다. .bss 섹션은 변수이며 .text 섹션의 위치와 관계없이 RAM에있게됩니다.

+0

좋은 설명 주셔서 감사합니다. –

3

예, 부트 로더 부팅 시스템 일반적으로뿐만 아니라 기본 부팅 경로를 차단하는 메커니즘을 제공하고 다른 펌웨어를 다운로드 할 수 있도록 대신 실행뿐만 아니라 다른 기능이 있습니다 (깜박임처럼).

전통적인 ROM에는 인터페이스, 주소, 데이터, 칩 선택, 읽기/쓰기 등의 전통적인 RAM이 있습니다. 그런데도 ROM을 구입할 수는 있지만 핀 부동산 관점에서 볼 때 SPI 또는 i2c 기반, 느린 것입니다. 달려가는 것은 바람직하지 않지만 한 번 읽은 다음 용납하십시오. 최신 플래시 기술은 읽기 방해와 관련하여 문제를 겪었을 수 있습니다. 코드가 꽉 짜인 루프에서 동일한 지침을 읽거나 다른 이유로 플래시가 너무 빨리 읽혀지면 읽기가 잘못 리턴 될 수 있습니다 데이터로 인해 프로그램이 코스를 변경하거나 충돌 할 수 있습니다. 또한 PC와 다른 리눅스 플랫폼은 NV 스토리지 (하드 디스크)에서 램으로 커널을 복사 한 다음 거기에서 실행되므로 플래시에서 RAM으로 복사하고 RAM에서 실행하는 것이 편안함을 제공하며 종종 플래시보다 빠릅니다. 따라서 플래시를 사용하지 않는 많은 잠재적 인 이유가 있지만 시스템에 따라 플래시에서 제대로 실행하는 것이 가능할 수도 있습니다 (일부 시스템에서는 해당 플래시가 직접 액세스 할 수없고 실행 가능하지 않음). 실행 가능/부팅 가능).

램에 무엇인가로 플래시를 프로그램하면 코딩상의 어려움이 간단 해집니다. 램에서 읽고 플래시에 쓰고 플래시에서 읽고 램에 쓰는 코드를 한 번 만들고 디버깅 할 수 있습니다. 끝난. 이제는 직렬에서 RAM으로 또는 RAM에서 직렬로 데이터를받는 별도의 코드로 작업 할 수 있습니다. 끝난. 그런 다음 이더넷이나 USB 또는 동일하게 작동하는 코드를 작성하십시오. 당신은 프로토콜을 발명하거나 타이밍 문제를 해결할 필요가 없습니다. 플래시 쓰기는 매우 느리며 적당한 속도의 xmodem조차도 너무 빠르기 때문에 xmodem이나 다른 직렬 기반 플래시 로더 대신에 RAM에 데이터를 버퍼링하여 작업을 완전히 분리 할 수 ​​있습니다 큰 RAM 기반의 FIFO를 사용하여 데이터를 RAM으로 이동 한 다음 RAM에서 플래시로 개별적으로 이동하십시오. 다른 인터페이스와 동일합니다. 기술적으로 데이터를 버퍼링하고 다운로드 인터페이스에서 곧바로 플래시로 전환 할 수 있다는 착각을 불러 일으킬 수 있습니다. 프로토콜에 따라 프로그래밍하기 전에 RAM에 플래시 페이지가 하나만 필요하도록 프로토콜을 전송하는 것은 기술적으로 가능합니다. 플래시. 더 오래된 병렬 섬광으로 당신은 나가 생각한 대부분의 사람들이 밖으로 생각한 매우 차가운 무언가를 할 수 있었다. 알려진 시간 동안 플래시 페이지에 쓰는 것을 멈 추면 플래시가 자동으로 해당 페이지를 프로그램하기 시작하고 완료되기 전에 10ms 정도 기다려야합니다.여러분이 순차 주소를 프로그램해야만했던 것과 그 기간에 다음 주소에 대한 새로운 데이터를 얻어야하고 높은 직렬 포트 속도 등을 요구한다면 여러분은 동일한 주소를 계속해서 반복 할 수 있다는 것입니다. 동일한 데이터와 플래시가 페이지를 프로그래밍하기 시작하지 않으며 다운로드 인터페이스가 매우 느려질 수 있습니다. 연속 플래시는 다르게 작동하며 트릭이 필요 없거나 다른 트릭을 사용합니다.

RAM/플래시는 산업 용어가 아닙니다. 이는 .text가 rom (플래시)이고 .data이고 .bss가 ram에 있음을 의미합니다. main()이 호출되기 전에 .data의 초기 상태 복사본이 flash에서도 ram에 복사되고, 마찬가지로 main()이 호출되기 전에 .bss가 0으로 설정됩니다. 부트 스트랩이 어떻게 일반적인 방식으로 작동하는지에 대한 요지를 얻으려면 gnu 소스 (glibc, 또는 gcc)에있는 대부분의 플랫폼에서 crt0.S를 살펴보십시오.

부트 로더가 리눅스 나 다른 운영체제를 실행할 필요는 없지만 uboot가 필요하지는 않지만 매우 유용합니다. 리눅스는 꽤 쉽습니다. 커널과 루트 파일 시스템을 복사하고, 메모리에 몇 가지 레지스터 또는 태그를 설정하거나, 둘 다 커널의 진입 점으로 분기하면 리눅스가 거기에서 인계합니다. 리눅스는 너무 복잡하기 때문에 이더넷과 같은 고속 인터페이스를 활용할 수있는 복잡한 부트 로더를 사용하는 것이 바람직합니다 (직렬 또는 저속으로 제한되는 것보다).

+0

좋은 설명 주셔서 감사합니다. 설명 –

2

질문과 관련하여 질문이 추가됩니다. Q2.

Q2 : 부트 로더가 응용 프로그램을 RAM으로 복사 한 다음 RAM에서 응용 프로그램을 실행해야하는 이유는 무엇입니까? FLASH에서 응용 프로그램을 실행하면 어떤 어려움을 겪게됩니까?

SPI 또는 이와 유사한 직렬 외부 코드 메모리 (어쨌든 자주 사용되지는 않음)가있는 것은 아닙니다.

일반적인 고속 병렬 버스에 연결된 외부 ROM/FLASH/EPROM /도 외부 메모리 액세스로 인해 비교적 느린 MCU에서도 시스템이 최대 클럭 (0 대기 상태)에서 실행되는 것을 방지합니다 시각. 100MHz 클럭에 대해 10ns의 플래시 액세스 시간이 필요합니다. 경제적으로 가능하다면 쉽게 얻을 수 없습니다.그리고 당신은 100 MHz가 더 이상 뇌 회전 속도가 아니라는 것에 동의 할 것입니다 :-)

많은 MCU/CPU 아키텍처가 한 번에 곱하기 명령어를 읽거나 내부 현금을 가지고 있거나 뭐든지 느린 외부 코드 메모리를 보완해야했습니다. 대부분의 오래된 8 비트 아키텍처 만이 플래시 메모리에서 직접 코드를 실행할 수 있습니다 ('적절한 위치에').

유일한 코드 메모리가 내부 플래시 인 경우에도 속도를 높이려면 수행해야 할 작업이 있습니다. 이 문서에서, 예를 들어 살펴 보자 :

http://www.iqmagazineonline.com/magazine/pdf/v_3_2_pdf/pg14-15-18-19-9Q6Phillips-Z.pdf

그것은이 ARM7 그들이 MAM (메모리 가속기 모듈)이라는 것을 통합 어떻게 desribes. 그것은 좋은 읽기, 당신은 특정 ARM7의 arhitecture의 코드 메모리 액세스 속도를 거기에 몇 가지 조치 (대부분의 다른 사람을 위해 간다) 찾을 수 :

  1. 제한 최대 클록 주파수 (80 MHz의 약 20 MHz의를 명령어 캐시가 N 인 경우 기사의 예) 플래시 동안
  2. 삽입 대기 사이클이
  3. 사용하는 명령 캐시에 액세스하기위한
  4. 복사 플래시에서 프로그램 코드는 분명히

를 RAM으로 o 옵션 (너무 작거나 클럭이 너무 높음)은 시작시 코드를 재배치 한 후 RAM에서 실행 만 남았습니다.

링커에 지정할 수있는 RAM의 특정 코드 섹션 만 실행하는 옵션이 있습니다. DSP (Digital System Processing) 시스템의 경우, 지금은 말할 것도없고, 수십 MHz 정도의 클록으로 옛날에도 EPROM/플래시에서 실행할 옵션이 없었습니다.

또 다른 문제는 디버깅입니다. ROM에 배치 된 코드를 디버깅하는 옵션이나 플래시도 매우 제한적입니다. 대부분의 시스템에서 중단 점을 설정하려면 코드 섹션을 RAM으로 이동해야합니다.

2

Q2와 관련하여 Flash에서 실행하기가 어려울 수있는 또 다른 코드 업데이트가 있습니다. 업데이트하려고하는 동일한 플래시 블록에서 실행중인 경우 시스템이 중단됩니다. 이는 시스템 아키텍처 (응용 프로그램과 부트 로더가 플래시로 구성되는 방식)에 달려 있지만 부트 로더 자체를 업데이트하려는 경우에는 특히 피하기 어려울 수 있습니다.