Bootloader工作

Question

我正在开发Uboot bootloader。关于Bootloader的功能和它将要处理的应用程序，我有一些基本的问题：

Q1:据我所知，bootloader用于将应用程序下载到内存中。在互联网上，我还发现bootloader将应用程序复制到RAM，然后应用程序从RAM运行。我搞不懂Bootloader...When应用程序是通过串口还是TFTP提供给bootloader的，接下来会发生什么，Bootloader是先把它复制到内存，还是直接写入闪存。

Q2:为什么需要Bootloader将应用程序复制到内存，然后从内存中运行应用程序？如果我们的应用程序从闪存运行，我们将面临哪些困难？

Q3：“我的应用程序从内存/闪存中运行”这句话是什么意思？这是否意味着我们的应用程序的.text段或.code段在内存/闪存中？我们并不关心.bss段，因为它是设计在内存中的。

谢谢Phogat

Answer 1

当设计任何硬件系统时，设计者必须考虑可执行代码将位于何处。答案取决于微控制器、所包含的内存类型和系统要求。因此，答案因系统而异。一些系统执行位于RAM中的代码。其他系统执行位于闪存中的代码。您没有告诉我们足够多的关于您的系统的信息，无法了解它的设计用途。

系统可能被设计为从RAM执行代码，因为RAM的访问速度比闪存快，所以代码可以执行得更快。系统可能被设计为从闪存执行代码，因为闪存很多，而RAM可能不多。系统可能被设计为从闪存执行代码，以便更快地引导。这些只是一些例子，还有其他一些考虑因素。

RAM是易失性的，因此它在电源循环过程中不会保留代码。如果系统执行位于RAM中的代码，则需要启动加载程序来获取代码并在加电时将代码写入RAM。闪存是非易失性的，所以可以在加电时立即开始执行，并且不需要引导加载程序(但可能仍然有用)。

关于Q3，答案是肯定的。如果系统是从内存运行的，那么.text将位于内存中(但直到引导加载程序将其复制到内存中之后)。如果系统从闪存运行，则.text部分将位于闪存中。.bss段是变量，无论.text段在哪里，它都会在内存中。

Answer 2

是的，引导加载程序通常会引导系统，但它也可能提供一种中断默认引导路径的机制，并允许下载并运行替代固件以及其他功能(如闪存)。

传统的只读存储器有一个传统的随机存取存储器，如接口、地址、数据、芯片选择、读/写等，你仍然可以用这种方式购买只读存储器，但从引脚的角度来看，使用基于spi或i2c的东西更便宜，这是较慢的。不希望从其中运行，但可以容忍读取一次，然后从ram中运行。较新的闪存技术可能/已经在读取干扰方面遇到了问题，如果您的代码处于读取相同指令的紧密循环中，或者由于读取闪存太快的任何其他原因，电荷可能会下降，从而导致读取返回错误的数据，从而可能导致程序改变路线或崩溃。此外，您的PC和其他linux平台习惯于将内核从NV存储(硬盘)复制到ram，然后从那里运行，因此从闪存复制到ram并从ram运行具有一定的舒适性，并且通常比闪存更快。因此，有许多不使用闪存的潜在原因，但是根据系统的不同，从闪存运行也是可能的(某些系统闪存不能直接访问并且不可执行，当然，该系统中的一些rom需要是可执行/可引导的)。

如果你用ram中的东西对闪存进行编程，它可以简化编程挑战。您可以创建和调试一次代码，该代码从ram读取并写入闪存，从闪存读取并写入ram。好了。现在，您可以使用单独的代码从串行接收数据到ram，或者从ram接收数据到串行。好了。然后编写在以太网或usb上执行相同操作的代码。您不必处理发明协议或解决时间问题的问题。闪存写入非常慢，即使是中等速度的xmodem也可能太快，所以无论如何你都必须在ram中缓冲这些数据，不妨使任务完全分离，而不是xmodem或任何其他基于串行的闪存加载程序，只需将数据移动到ram，然后从ram到flash。其他接口也是如此。在技术上可以缓冲数据并给出从下载接口直接到闪存的假象，并且根据协议，在技术上可以延迟发送器，使得在编程闪存之前在ram中只需要一个闪存页面。使用较老的并行闪光灯，你可以做一些很酷的事情，我想大多数人都想不到。当您停止写入闪存页面一段已知时间后，闪存将自动开始对该页面进行编程，您必须等待10ms或类似的时间才能完成。人们假设你必须对顺序地址进行编程，并且必须在这段时间内获得下一个地址的新数据，并且需要高串口速度，等等。现实是，你可以用相同的数据一次又一次地敲打相同的地址，而闪存不会开始对页面进行编程，并且下载界面可能会无限慢。连续闪光的工作方式不同，要么不需要技巧，要么有不同的技巧。

RAM/FLASH不是什么行业术语。这可能意味着.text在rom (闪存)中，而.data和.bss在ram中。.data的初始状态的副本可能也在闪存中，并在调用main()之前复制到ram中，同样，.bss在调用main()之前将被清零。查看gnu源代码中大多数平台的crt0.S (glibc，或者是gcc，我不知道)，以获得引导如何以通用方式工作的要点。

运行linux或其他操作系统不需要引导装载器，也不需要uboot，但它非常有用。Linux非常简单，你复制内核和根文件系统，或者在内存中设置一些寄存器或标签，或者两者都设置，然后分支到内核的入口点，linux就会从那里接管。因为linux是如此复杂，所以需要有一个复杂的引导加载程序，它可以利用像以太网这样的高速接口(而不是局限于串行或更慢的接口)。

Answer 3

我想补充一些关于你的问题Q2。

Q2:为什么需要Bootloader将应用程序复制到内存，然后从内存中运行应用程序？如果我们的应用程序从闪存运行，我们将面临哪些困难？

这不仅仅是关于拥有SPI或类似的串行外部代码存储器(无论如何，这并不是那么频繁)。

即使连接到通常的高速并行总线的外部ROM/FLASH/EPROM/也将阻止系统在最大时钟(具有零等待状态)上运行，即使在由于外部存储器访问时间而相对较慢的MCU上也是如此。对于100 MHz的时钟，您需要10 ns的闪存访问时间，这不是那么容易获得的(如果经济上可行的话)。你会同意100 MHz不再是一个大脑旋转的速度了:-)

这就是为什么许多MCU/CPU架构都在一次读取多条指令，或者拥有内部现金，或者做任何需要补偿缓慢的外部代码存储器的事情。只有大多数较老的8位架构可以直接从闪存中执行代码(“就地”)。

即使你唯一的代码存储器是内部闪存，也需要做一些事情来加速它。看看这篇文章中的例子：

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

它描述了ARM7是如何结合他们称为内存加速器模块的东西的。这是一个很好的读物，你会在那里找到一些方法来加速特定ARM7架构的代码内存访问(适用于大多数其他架构)：

1. 限制最大时钟频率(例如，闪存访问期间的article)
2. Insert等待周期从80 MHz到约20 MHz )
3. 使用指令缓存
4. 将程序代码从闪存拷贝到

显然，如果指令缓存不是一个选项(太小，或者时钟太高)，那么在启动时重新定位代码后，您实际上只剩下从RAM执行。

还可以选择只运行RAM中的特定代码段，这可以指定给链接器。对于数字系统处理系统来说，即使在时钟只有几十MHz的旧时代，也没有从EPROM/FLASH运行的选择，更不用说现在了。

另一个问题是调试，用于调试ROM甚至Flash中的代码的选项非常有限(您必须将代码的一部分移动到RAM才能在大多数系统上设置断点)。