U-Boot设计的10条黄金法则

U-Boot设计的10条黄金法则

ps:此篇为翻译,原英文请看官网:https://www.denx.de/wiki/view/U-Boot/DesignPrinciples

1.保持小巧

U-Boot是引导加载程序,即,它的主要目的是加载某些操作系统。您不需要投入任何大量资源。通常,U-Boot存储在相对较小的nor flash中。

(u-boot 大小通常在512KB以下 ,denx 官网说的 128KB 256KB)

2.保持快速

最终用户对运行U-Boot不感兴趣。在大多数嵌入式系统中,他甚至不知道U-Boot的存在。用户希望运行一些应用程序代码,并在打开设备后尽快运行。

因此,至关重要的是,U-Boot必须尽可能快,尤其是它必须尽可能快地加载和引导操作系统。

为此,应遵循以下设计原则:

  • 尽快并尽可能启用缓存
  • 仅在U-Boot中需要它们时才初始化设备,即,除非U-Boot通过以太网执行下载,否则不要初始化以太网接口。不要初始化任何IDE或USB设备,除非U-Boot实际上尝试从其中加载文件等(并且不要忘记在使用它们后关闭这些设备-否则,当您尝试引导操作系统时,可能会发生不开心的事情)。

而且,U-Boot的构建应尽可能快。这使得为所有受支持的配置或至少为特定体系结构的所有配置运行构建更加容易,这对于保证质量至关重要。如果建造麻烦且缓慢,大多数人将就此放弃。

3.保持简单

U-Boot是引导加载程序,但它也是用于板子启动,生产测试和其他活动的工具

4.保持可移植

U-Boot是引导加载程序,但它也是用于板子启动,生产测试以及与硬件开发非常相关的其他活动的工具。到目前为止,它已被移植到大约30个不同处理器系列的数百个不同板上,请确保您添加的任何代码都可以在尽可能多的不同平台上使用。

尽可能避免使用汇编语言-只有带有基本CPU初始化的复位代码,和静态DRAM初始化和C堆栈设置等要使用汇编。所有进一步的初始化都应使用C代码完成。这些功能代表某种HAL(硬件抽象层)功能,应在所有体系结构上一致定义。例如基本的MMU和缓存控制,堆栈指针操作。不存在的函数应扩展为空宏或错误代码。

不要对运行U-Boot的环境做任何假设。它可能在直接连接的串行控制台上与人工操作员进行通信,但是也可以通过GSM调制解调器,或由某些自动测试或控制系统来驱动。因此,请勿输出任何精美的控制字符序列或类似字符。

5.保持可配置

“保持小巧”部分已经在一侧说明了有关U-Boot大小的限制。另一方面,U-Boot是一个功能强大的工具,具有许多非常有用的功能。每个板子的维护者或用户将必须决定哪些功能对他很重要,以及特定的板子配置应包含哪些功能以满足其当前的要求和限制。

请确保从板配置中轻松添加或删除功能,以便每个人都可以在其系统上充分利用U-Boot。

如果不包括功能,则该功能不应有任何残留代码参与编译,使得目标文件显得臃肿。

6.保持可调试

可调试代码对于我们所有人来说是一个很大的好处。但是,正如上面“保持可移植”部分中已经提到的那样,U-Boot本身不仅是一种工具,而且还经常用于硬件启动,因此调试U-Boot通常意味着我们不知道是U-Boot软件的问题还是硬件的问题,干净,易于理解和调试的代码对我们许多人而言都变得越来越重要。

  • U-Boot的一项重要功能是在启动过程中尽快将输出输出到(通常是串行的)控制台,即使这会在内存占用等其他方面造成折衷。
  • 所有初始化步骤应在实际开始之前打印一些“开始执行”消息,并在完成时打印一些“完成”消息。例如,RAM初始化和大小检测可以在启动之前打印“ RAM:”,完成时打印“ 256 MB \ n”。这样做的目的是,如果有任何问题,您始终可以看到正在运行哪个初始化步骤。这不仅在软件开发期间很重要,而且对于在现场处理损坏的硬件的服务人员也很重要。
  • U-Boot应该可以使用简单的JTAG或BDM设备进行调试。它应使用简单的单线程执行模型。避免使用任何魔术,即使只有1个或2个硬件断点可用,也可能妨碍简单的调试。

7.保持可用性

请始终记住,U-Boot至少有三个不同的用户组,它们的期望和要求完全不同:

  • 嵌入式设备的最终用户,他们只想运行某些应用程序。他甚至不希望知道U-Boot的存在,并且很少与它进行交互。
  • 从事应用程序或操作系统开发的设计人员和工程师,他们想要一个功能强大的工具,该工具可以从他们可以想象的任何设备中启动,他们希望它快速且可编写脚本,并且无论如何-总之,他们想要支持尽可能多的功能,还有更多。
  • 将U-Boot移植到新电路板上的工程师和电路板维护者,他们希望U-Boot尽可能简单,这样,将其移植并维护在其硬件上就很容易。
  • 使其易于测试。添加调试代码(但不要重新发明轮子-使用现有的宏,例如debug()或debugX())。

请始终记住,U-Boot会尝试满足所有这些不同的要求。

8.保持可维护性

  • #ifdefs尽可能 避免
  • 使用“弱”功能
  • 始终遵循代码风格要求。

9.保持美丽

  • 保持源代码整洁:严格遵循代码风格,保持列表(Makefile中的目标名称,板名称等)按字母顺序排序等。
  • 保持U-Boot控制台输出整洁:仅输出真正必要的信息,简洁而精确,使输出保持垂直对齐,不要使用控制字符序列(例如,使用退格键或\ r来执行“纺车”活动指示符)等。

10.保持开源

黄金法则中的引理

1.通用代码就是好代码

新代码应尽可能通用,添加到U-Boot抽象层次结构中的尽可能高的层次。

猜你喜欢

转载自blog.csdn.net/agave7/article/details/108824958