마이크로 컨트롤러의 응용 프로그램과 별개의 부트 로더가 필요한 이유는 무엇입니까?

28

마이크로 컨트롤러의 동일한 플래시 프로그램 메모리, 특히 부트로 더라고하는 STM32F103에 별도의 프로그램이 필요한 이유는 무엇입니까?

기본 응용 프로그램과 분리하여 유지하는 데있어 특별한 점은 무엇입니까?

일반적으로 마이크로 프로세서 기반 시스템 (예 : PowerPC MPC8270)의 부트 로더는 마이크로 컨트롤러 (ARM STM32F103)와 동일한 작업을 수행하거나 기본적으로 서로 다른 작업을 수행하지만 둘 다 '부트 로더'라고합니다. ?

— 대체 장미
소스

2

하나의 거대한 모 놀리 식 구조가 아닌 개별 칩과 부품이있는 것과 동일한 이유

— Emobe

당신은하지 않습니다. 컴퓨터 콘솔의 스위치와 표시등으로 프로그램을 입력하십시오.

— 핫 릭

1

엄밀히 말하면 마이크로 컨트롤러에 별도의 부트 로더 프로그램이 필요하지 않습니다. 그러나 우리는 종종 추가 유틸리티 기능을 제공하기 위해 하나를 선택합니다. 이러한 기능이 필요하지 않은 경우 원하지 않는 경우 부트 로더를 제거 할 수 있습니다. 마이크로 컨트롤러 부트 로더는 일반적으로 새 프로그램을 플래시에 레코딩하는 데 사용됩니다. 때로는 디버깅 기능, 일부 지원 중단 점 및 기타 유용한 기능에 사용할 수 있습니다. 마이크로 컴퓨터에서는 일반적으로 부트 로더가 대용량 메모리에서 프로그램을로드하므로 여기에 필요합니다.

— ghellquist

55

마이크로 컨트롤러의 부트 로더는 프로그래밍 헤더 이외의 통신 채널을 통해 주 펌웨어를 업데이트합니다. 이는 BLE, UART, I2C, SD 카드, USB 등을 통해 현장에서 펌웨어를 업데이트하는 데 유용합니다. 고객이 장치의 펌웨어를 업데이트하기 위해 프로그래머를 구매하도록 요구하는 것은 매우 불편합니다.

부트 로더가 분리되어 유지되는 이유는 신뢰성입니다. 부트 로더와 응용 프로그램 코드는 별도의 플래시 섹션에 배치되므로 부트 로더 코드와 관련된 내용을 변경하지 않고도 응용 프로그램 코드를 지우고 부트 로더가 다시 작성할 수 있습니다.

부트 로더와 응용 프로그램이 함께 유지 된 경우 펌웨어 업데이트로 인해 부트 로더 코드가 플래시로 지워 지므로 부트 로더 코드를 실행하기 전에 RAM에 복사해야합니다. RAM의 부트 로더 코드로 전원이 차단되고 플래시가 지워지면 장치가 브릭 킹됩니다.

— 커티스
소스

3

우리도 마찬가지입니다. 그것들은 같은 플래시에 있지만 부트 로더는 플래시 소거 경계가 정렬되어 있으며 자체 주소보다 높은 플래시 만 지울 정도로 똑똑합니다.

— 여호수아

3

경우에 따라 제품 섀시를 분해하지 않고도 마이크로 프로세서의 프로그래밍 헤더에 실제로 액세스 할 수 없으므로 추가 하드웨어없이 통신 버스를 통해 다시 프로그래밍 할 수있는 것이 안정성의 핵심 요소입니다.

— John Go-Soco

6

@ alt-rose 부트 로더와 응용 프로그램은 각각 고유 한 시작 코드와 main()기능을 가진 개별적으로 컴파일 된 프로그램 입니다. 전원을 켤 때 부트 로더 시작 코드가 실행되고 부트 로더를 호출합니다 main(). 부트 로더 프로그램은 유효한 응용 프로그램을 확인한 다음 응용 프로그램을 호출하는 응용 프로그램의 시작 코드로 이동합니다 main(). 각 프로그램의 시작 코드는 각 프로그램에 대한 C 런타임 환경을 초기화합니다 (예 : 변수, 스택 등 초기화). 일반적으로 프로그램 main()이 시작 코드로 돌아 가지 않습니다 .

— kkrambo

1

@ alt-rose : CPU가 부트 로더의 시작 주소를 얻는 것과 같은 방식으로-그렇지 않습니다. 대신, CPU는 부트 로더의 시작 주소로 사용할 것을 지정하고 부트 로더는 응용 프로그램의 시작 주소로 사용할 것을 지정합니다.

— MSalters

4

@kkrambo 일반적으로 사실이지만 부트 로더를 C 또는 C 파생 언어로 작성해야 할 필요는 없습니다 main.

— 야크

26

로딩 과정에서 오류를 복구 할 수 있습니다. 업그레이드 중에 통신 오류가 있거나 전원이 끊겼다 고 가정하십시오. 부트 로더가 업그레이드중인 응용 프로그램의 일부인 경우 사용자는 특수 하드웨어를 사용하여 부트 로더로 다시 플래시하지 않고 다시 시도 할 수 없습니다.
일부 마이크로 컨트롤러는 RAM에서 코드를 실행할 수 없습니다. 부트 로더가 나머지 소프트웨어와 혼합 된 경우 현재 실행중인 플래시 페이지를 지울 수 없기 때문에 실제로 소프트웨어를 업그레이드 할 수 없습니다. 이 문제를 해결하려면 먼저 새 코드를 플래시의 후반부에 굽고 점프하십시오. 그런 다음 새 코드는 플래시의 전반부에 자신을 복사합니다. 물론 단점은 일반적으로 플래시 레코딩 속도가 느리고 이제 두 번로드해야하므로 로딩 프로세스에 최대 두 배가 걸릴 수 있다는 것입니다. 또한이 해결 방법은 응용 프로그램 크기가 전체 플래시의 절반보다 크지 않도록 제한합니다.
잘 작성된 부트 로더는 장치를 실행하기 전에 장치에 유효한 코드가 있는지 확인하려고합니다. 부트 로더와 다른 코드가 혼합 된 경우 모든 코드가로드되지 않은 경우 유효성 검사 루틴이 작동하는지 어떻게 확인할 수 있습니까?
입증. 보안 부팅 로더는 실행하기 전에로드 된 응용 프로그램이 디지털 서명과 일치하는지 확인합니다. 그러나 부트 로더와 다른 코드가 함께 혼합 된 경우 사용자가 새 코드를로드하면 시작시 발생하는 작업을 제어 할 수 없으므로 장치에서 실행되는 작업을 제어 할 수 없습니다.

— 사용자
소스

4

포인트 2의 예로, 일부 마이크로 컨트롤러는 시작시 액세스 가능한 RAM 이 없을 수도 있습니다 . 예를 들어, Raspberry Pi 는 GPU를 사용하여 SD 카드에서 부트 로더를로드 한 다음 ARM 프로세서 및 메모리를 활성화합니다.

— ErikF

11

일반적으로 기본 응용 프로그램을 업데이트 할 수 있습니다.

내부 플래시의 일부를 지우고 다시 프로그래밍하는 방법을 알고있는 코드가 필요합니다.이 플래시는 자체 프로그램을 지울 때 다시 프로그래밍 할 수없는 것처럼 메인 프로그램이 될 수 없습니다.

— 콜린
소스

9

부트 로더를 사용하면 MCU가 다른 프로그램과 통신하여 새 프로그램을 수락하고 저장 한 후 재설정 후 실행할 수 있습니다. 부트 로더가없는 경우 메모리에 액세스하고 프로그램을 설치하려면 프로그래머가 필요합니다.

— 교차로
소스

2

거의 다됐다. MCU는 특수 프로그래밍 서브 시스템 (예 : AVRICE 또는 JTAG)을 통해 또는 이미 부트 로더를 플래시로 사용하여 코드를 가져올 수 있습니다. 부트 로더가 얼마나 복잡한 지에 대한 애플리케이션 결정입니다. 예를 들어 일부 시스템은 WiFi에서 코드를로드 할 수 있습니다. ATTiny와 같은 초저가 MCU에서는 부트 로더 (및 직렬 핀)가 큰 오버 헤드이므로 항상 프로그래머를 사용하십시오.

— 리치

7

In addition to the other correct answers about allowing reprogramming of the main firmware from the bootloader, another benefit of having the bootloader be separate is that you can logically separate the "do once on boot" tasks from the code you need during runtime. Then, after the bootloader finishes its initial configuration tasks, the main firmware can evict the bootloader with all its no-longer-needed code from memory, saving significant RAM space. It's possible to achieve this in other ways, but the bootloader/firmware split makes it much easier on many architectures.

— Nate S - Reinstate Monica
소스

1

On a microcontroller, the code most likely never is in RAM, so it can't be evicted. You can discard the bootloader's data from RAM of course.

— Ben Voigt

@BenVoigt, it depends on the microcontroller. Some (primarily those with NOR flash) will let you execute directly out of flash, but others (usually with NAND flash, which is becoming more common) require you to execute out of RAM. Sometimes there isn't even any on-board flash, and you have to copy the code from an external flash chip into local SRAM before you can execute anything.

— Nate S - Reinstate Monica

2

The short answer, is because software is awesome.

You could have everything the bootloader does be "pure hardware". But it is far, far, far easier to have the tasks the bootloader does be written as software, then interpreted by hardware.

These tasks can involve setting up the hardware for the "real" software to run (for example, on a Raspberry Pi (via @ErikF)), having a protocol to replace the "real" program before it runs (check a pin, if that pin is set then reflash the real program), or even setting up the software environment for the "real" program.

On less micro-scale software, when you run an executable the application loader moves does stuff like loading parts of your data into memory, sometimes fixes up addresses, sets up arguments to main or other global stuff, spins up your OS provided libraries, and then jumps to the start of the _main code. Some of these things can be done by a bootloader.

In a microcontroller, some of the tasks that a bootloader does could be split off into the program. The compiler for your platform could automatically inject the "setup" code into every executable.

But, having it in the bootloader means that the same compiler might work on different hardware, as the bootloader can "hide" the difference between the platforms.

Top that off with the fact that a flash of the main program doesn't risk the bootloader (and the ability to reflash the main program), and having a non-trivial bootloader is a pretty great thing.

— Yakk
소스

-1

One answer that hasn't been covered is the need for separation of concerns due to the limitations of the C language.

Generally bootloaders are written in a mix of Assembly and C, with the very early boot stage in Assembly.

This is done to setup certain things like:

allocating the C stack
reading the stack pointer into the register
reading the program counter into the register
declaring reset vectors
loading the second stage (initramfs) into RAM.

This is a very rough approximation of the steps taken and I am describing the ARM boot process, it is different again for x86 and other architectures.

However, the principle reason remains the same: allocating the C stack must be done from assembly.

— BitShift
소스

Why the downvote? This is both relevant and accurate.

— BitShift

-1

One part of the question that hasn't been answered so far is the difference between bootloaders on microcontrollers and microprocessor systems.

Microcontroller

Most microcontrollers have built-in ROM memory that contains their program code. Changing this code usually requires a programmer device that connects to the programming interface of the microcontroller (e.g. ISP on ATMega). But these programming interfaces usually often are not very convenient to use, compared to other interfaces, since they might not be readily available in the given context. So for example, while almost every computer features USB ports, the SPI interface needed for ISP is much rarer, and other interfaces like the PID interface used on ATXMega are only supported by dedicated programming hardware.

So, e.g., if you want to update the software from a regular computer without any external hardware you can use a bootloader that reads from a different kind of interface (e.g. RS232, USB or RS232 over USB like on the Arduino) to program the device over common interfaces.

That said, if you don't need this functionality the bootloader is completely optional. The microcontroller can still run it's code completely without the bootloader.

Microprocessor

On a microprocessor things are a little different. While most microprocessors feature a ROM that is large enough for a bootloader, those ROMs are not nearly large enough to hold a full OS. So the purpose of the bootloader is to initialise hardware, look for a bootable OS, load it and run it. So the bootloader is critical for every single boot.

On x86/x64 systems this bootloader is either the BIOS or the UEFI (basically a newer version of a BIOS).

Sometimes you might even have multiple bootloaders running in a chain. For example if you have a dual-boot system with Windows and Linux you might end up with the following:

BIOS/UEFI boots up and finds GRUB installed. It then loads GRUB (=Grand Unified Bootloader)
GRUB finds some kind of Linux and the Windows Bootloader. The user selects the Windows Bootloader.
The Windows bootloader starts and finds Windows 7 and Windows 10 installed. The user selects Windows 10.
Windows 10 finally boots.

So in this case there were three pieces of software that can be considered a bootloader. Both GRUB and the Windows Bootloader are mostly there to give the user a more convenient boot selection option than the BIOS/UEFI would give them. It also allows for multiple OSes to be launched from the same hard drive or even the same partition.

TLDR

So while in both systems the bootloader does kinda similar things (helping the user to choose what code to boot) they both differ greatly in how they accomplish that and what they do exactly.

— Dakkaron
소스

While it's useful to distinguish systems with enough random-access non-volatile storage (ROM or flash) to hold the entire program from those that need to run code from RAM, there are microcontrollers of both types and microprocessors of both types.

— supercat

Of course the difference between a microcontroller and a microprocessor is not a hard border and some microcontrollers behave more like a microprocessor and vice versa. That's why I took the AtMega/Arduino and the x86/x64 as examples, because they behave in that way.

— Dakkaron

"microprocessors feature a ROM that is large enough for a bootloader... On x86/x64 systems this bootloader is either the BIOS or the UEFI" Nope. BIOS or UEFI are stored in off-chip flash memory. The on-chip ROM is for even lower level functions, like initialization of the microcode.

— Ben Voigt

@Dakkaron: I would draw the line between a microprocessor and microcontroller based upon whether the chip is designed to be usable for non-trivial purposes without anything else on the address bus. The 8031 wouldn't qualify except that it is functionally 8051 (which is definitely a microcontroller) which isn't specified as having anything useful in the internal ROM, but would otherwise be designed to be usable entirely from internal storage). Something like an RCA/CDP 1802 wouldn't qualify even though it can be used to drive an LED nametag...

— supercat

...with no external RAM and ROM, because RAMless/ROMless designs are limited to trivial tasks. Something like a TMS 32050 which if I recall has a bootloader and a few thousand words 16-bit words of RAM internally would qualify as a microcontroller, however; although many applications would require more adding more RAM, if connected via UART to another system it could serve many purposes without anything on its memory bus.

— supercat