嵌入式系统中的引导加载程序和启动代码是什么？ [英] What is the bootloader and startup code in embedded systems?
问题描述
这些放在哪里？以及从复位电源到应用程序启动的流程概述。考虑到一般的平台。
所有处理器都有一些处理器特定的启动方式。通常在处理器地址空间中有一些地址，例如，处理器读取该内存的地址为0xFFFF0000。它发现它用作代码的代码并开始在该地址执行代码。
芯片或电路板设计人员将做什么硬件是确保闪存或一些其他形式的非易失性存储器（ROM）被映射到该地址空间中，使得处理器的引导代码和该特定地址处的引导代码的地址将在处理器在电源打开时读取并且复位被释放（RAM是易失的，关闭电源，并且丢失数据，重新打开它，并获得一些随机数据，直到RAM被写入其他东西）。
因此，处理器运行的第一个代码通常称为引导加载程序，有些可能会争论说，加载器的后半部分意味着此代码可以引导操作系统或任何应用程序运行，并且作为第二个功能为开发人员提供加载程序功能。如果您曾经使用 U-Boot 或甚至 GRUB 或许多其他引导程序，您可能会明白，如果您没有触摸任何内容，它将启动默认值，嵌入式应用程序或操作系统，任何但是，如果您中断引导过程，并且中断该过程对平台和软件非常特别，有时您必须将按钮或短两个引脚连在一起或在串行/ UART 端口等上发送转义或其他字符，以及那么它进入加载器模式，您可能可以更改其引导的内容和/或代替引导程序加载Flash / ROM中的默认程序，它可能会让您使用 XMODEM 或<一个href =https://en.wikipedia.org/wiki/ZMODEM =noreferrer> ZMODEM 或以太网端口和协议将测试程序加载到RAM中，然后让您运行该程序一些人称引导软件是一个引导加载程序，即使它不允许你中断进程并加载一些备用程序，因为启动代码可能是从非易失性存储器将应用程序加载到RAM中。
并非所有引导程序都需要从非易失性存储（flash / ROM，hard磁盘，CD-ROM等）连接到RAM。某些系统和一些应用程序从闪存/ ROM运行。例如：PC中的真正的启动程序是BIOS，它是一个存储在闪存/ ROM中的程序。对于像PC一样的 DRAM 的系统，无论如何，您必须启动DRAM系统。配置硬件需要大量代码才能使DRAM工作，有时您可以在PC上启动显示器上的某些状态。如果您的系统中有 SRAM ，那么它也可能需要一些初始化，但通常不会几乎像DRAM一样复杂，通常它很快就可以使用很少或没有配置，不同的处理器和不同的系统是不同的。
所以处理器在某种程度上在处理器硬件中被硬编码。它已经找到引导代码的入口点，并开始执行该代码。那个代码一般需要让外设和RAM运行起来，然后运行主应用程序。或者在启动应用程序之前至少需要硬件。
在嵌入式系统中加载Linux可以像获取RAM一样简单，并将内核从ROM复制到RAM，可能准备一些寄存器，也许填写内核看的几个内存位置，例如内存大小和备用命令行，然后分支到内核的启动。您不必在某些系统上复制内核;你可以分支到它所在的ROM。那么Linux将会弹出系统的其余部分。在PC上，BIOS会执行很多操作，例如播放视频，DRAM，列举 PCI （e）总线外围设备，打开硬盘或其他文件系统，如设备，然后使用用户在BIOS硬盘或外围设备（USB拇指驱动器或CD-ROM等）中定义的。文件系统的开始将包含一些如何根据BIOS代码的规则引导操作系统。这可能是另一个引导程序（GRUB，U-Boot等），最终将内核或操作系统启动代码复制到RAM中，然后分支到... ...
术语引导加载程序和启动代码可以互换使用。一些人可能会挑剔他们是不同或微妙的差异，但它通常与复杂性有关，像U-Boot这样的引导程序，它具有以太网驱动程序和文件系统驱动程序等，在某种程度上是一个操作系统自我，任何一种方式U-Boot是非常复杂的。
例如，微控制器的启动代码可能与几行代码一样简单，设置堆栈指针，并分支到main。而启动代码/引导程序可以是任何级别的复杂性之间。如前所述，一些嵌入式系统从ROM启动并运行其应用程序，因此不需要复制和运行。其他需要复制并运行的主要应用程序。
有时硬件或其他方案涉及。例如，有许多基于FPGA 的解决方案，其中硬件读取的内容从ROM启动并复制它。然后当处理器或其他逻辑被释放时，您的程序或其他数据在RAM中是神奇的，准备使用。即使当电源关闭时，它仍然存在于您通常不会触摸的ROM中。 Raspberry Pi 还有另一种解决方案。该芯片有两个处理器，一个是ARM，另一个是 GPU ，图形处理器，完全不同的指令集，专为数学运算而设计等等。在某种形式中，烧录到芯片中（可能是芯片上的一个ROM）一个刚刚足够启动和读取SD卡的小型引导加载程序。这是GPU BTW; ARM处于复位状态。然后，GPU从SD卡读取其第一个引导加载程序文件，将其复制到RAM并运行。
该引导程序执行更多的操作，例如启动DRAM，然后复制从SD卡到DRAM的更复杂的第二（第三？）级引导加载程序运行。该代码可能包含用于执行系统的屏幕/显示功能的GPU应用程序。一旦视频和一切准备就绪，再次读取SD卡，将ARM应用程序从SD卡复制到DRAM，在RAM中填入几个项目（异常表中的引导向量（分支到内核））以及Linux内核引导代码所需的已知位置的其他一些项目。然后它会释放ARM上的复位。 ARM在这一点唤醒了它的应用，内核，神奇地在RAM中...
What is the basic significance of bootloader and startup code in the embedded systems? What is the difference?
Where are these placed?? And an overview of the flow from power on reset to the application start. Considering any platform in general.
All processors have some processor-specific way of starting. Usually there is some address in the processors address space, let’s say 0xFFFF0000 for example, where the processor reads that memory. The value it finds it uses as an address to code and starts executing code at that address.
What the hardware either chip or board designers would do is make sure that a flash or some other form of non volatile memory (ROM) is mapped into that address space, so that the processor's boot code and that address to the boot code at that special address, will be there for the processor to read when the power is turned on and reset is released (RAM is volatile, turn off the power and you lose the data, turn it back on and you get some random data until such time as the RAM is written with something else).
So the first code a processor runs is often called the bootloader, and some may debate that the latter half of the word loader implies that this code can both "boot" the operating system or whatever application is to be run, and also as a second function provide a "loader" capability for developers. If you have ever used U-Boot or even GRUB or many other bootloaders you might understand that if you don't touch anything it will boot the default whatever, embedded application or operating system, whatever.
But if you interrupt the boot process, and interrupting that process is very specific to the platform and software, sometimes you have to push a button or short two pins together or send an escape or some other character in on a serial/UART port, etc., and then it goes into the loader mode where you might be able to change what it boots and/or instead of the bootloader loading the default program from flash/ROM it might let you for example use XMODEM or ZMODEM or an Ethernet port and protocol to load a test program into RAM, then let you run that program instead of the default program.
Some folks call the boot software a bootloader even if it doesn't allow you to interrupt the process and load some alternate program, because that boot code might be "loading" the application into RAM from non-volative storage anyway.
Not all bootloaders need to copy the application from non-volatile storage (flash/ROM, hard disk, CD-ROM, etc.) to RAM. Some systems and some applications run from the flash/ROM. A PC for example: The real bootloader in a PC is the BIOS which is a program that lives in and runs from flash/ROM. For systems with DRAM like a PC, you have to bring up the DRAM system anyway. There is a lot of code required to configure the hardware such that DRAM works, and sometimes you can see some status of this on the monitor as a PC boots. If you have SRAM in your system then it may also require some initialization, but usually not nearly as complicated as DRAM, and often it is instantly up and ready to use with little or no configuration, different processors and different systems are...different.
So the processor is out of reset, in some manner hardcoded in the processor hardware. It has found the entry point to the boot code and started executing that code. That code then in general needs to get the peripherals and RAM up and running and then run the main application. Or at least as much hardware is needed before starting that application.
Loading Linux in an embedded system can be as simple as getting RAM up, and copying the kernel from ROM to RAM, maybe preparing some registers and maybe filling in a few memory locations that the kernel looks at with maybe memory size and an alternate command line for example, then branch to the start of the kernel. You don't have to copy the kernel on some systems; you can just branch to ROM where it lives. Then Linux will bring up the rest of the system. On a PC the BIOS does a lot of stuff, like bring up video, DRAM, enumerate the PCI(e) bus peripherals, bring up the hard disk or other filesystem like devices, then using the defined by user in the BIOS hard disk or like peripheral (USB thumb drive or CD-ROM, etc.). The beginning of the file system will contain some sort of how to boot the operating system based on the rules of the BIOS code. And that may be yet another bootloader (GRUB, U-Boot, etc.), which ultimately copies the kernel or operating system startup code to RAM and then branches to it...
The terms bootloader and startup code can be used interchangeably. Some folks may get picky about them being different or subtle differences, but it usually has to do with complexity, a bootloader like U-Boot which has Ethernet drivers and file system drivers, etc. is to some extent an operating system in and of it self, either way U-Boot is very complicated.
Startup code for a microcontroller, for example, may be as simple as a few lines of code, set stack pointer, and branch to main. And the startup code/bootloader can be any level of complexity in between. As mentioned already, some embedded systems boot from and run their applications from ROM so no copy and run is needed. Others require the copy and run for the main application.
Sometimes the hardware or some other scheme gets involved. It is possible, for example, many FPGA-based solutions, where the hardware reads stuff on power up from a ROM and copies it. Then when the processor or other logic is released, your program or other data is magically there in RAM, ready to use. Even though when the power is off it lives in a ROM that you don't normally touch. The Raspberry Pi has yet another solution. The chip has two processors, one is the ARM and the other is a GPU, graphics processor, completely different instruction set, designed for math operations, etc. There is in some form, burned into the chip (likely a ROM on the chip) a small bootloader that is just enough to bring up and read the SD card. This is GPU BTW; the ARM is in reset. The GPU then reads its first bootloader file from the SD card, copies that to RAM and runs it.
That bootloader does more things, like bring up DRAM, and then copies the more complicated second (third?)-stage bootloader from the SD card to DRAM then runs that. That code likely contains the GPU application for doing the screen/display functions for the system. It also, once video and everything is ready, reads the SD card one more time and copies the ARM application from SD card to DRAM, fills in a few items in RAM (boot vector in the exception table (a branch to the kernel)) and some other items at known locations that the Linux kernel boot code wants. Then it releases reset on the ARM. The ARM at this point wakes up with its application, the kernel, magically in RAM...
这篇关于嵌入式系统中的引导加载程序和启动代码是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
