首页 文章

用于ARM U-Boot构建问题的交叉工具链

提问于
浏览
3

我正在尝试为Raspberry-Pi构建自己的工具链 . 我知道有很多预建的工具链 . 这项工作是出于教育原因 . 我从头开始关注嵌入式arm linux . 到目前为止成功构建了gcc和uClib . 我正在为目标arm-unknown-linux-eabi构建 .

现在谈到准备一个可启动的文件系统我正在质疑自己的引导程序构建 .

有关此系统的引导加载程序的部分似乎不完整 . 现在我在质疑自己如何使用arm-unknown-linux-eabi工具链为这个系统构建一个uboot .

我是否需要构建一个不依赖于Linux内核调用的工具链 . 我的第一个研究引导我指出,操作系统依赖的是独立的工具链(Linux内核系统调用等......)以及不需要内核的工具链 . 有时称为“裸金属”工具链或“独立”工具链 .

一些消息来源提到可以使用linux工具链构建U-Boot . 如果这是真的,为什么以及如何运作呢?

如果我必须为“Bare Metal”工具链构建第二个工具链,我在哪里可以找到有关这两者之间差异的信息 . 我需要另一个libstdc吗?

2 回答

  • 1

    几乎所有可能的方式,嵌入式和Linux工具链之间没有区别 . 但有一个例外 .

    该异常是__clear_cache - 一个可以由编译器生成的函数,并且在"Linux" -toolchain中包含用于同步指令和数据高速缓存的系统调用 . (有关该位的更多信息,请参见http://blogs.arm.com/software-enablement/141-caches-and-self-modifying-code/ . )

    现在,除非你明确地添加对该函数的调用,否则我知道调用它的唯一方法是在C中编写嵌套函数(应该避免的GCC扩展) . 但这是一个区别 .

  • 1

    您可以使用用于构建内核的相同交叉工具链来构建U-Boot - 并且很可能是系统的其余用户空间 .

    根据定义,引导加载程序是自包含的,并不关心您选择的C运行时库,因为它不使用它 . 因此,sys-calls的问题不会进入它 .

    工具链总是需要由功能完备的开发系统托管 - 总是不是您的目标系统 . 无论您对“裸机工具链”看到什么参考,都不是指编译器使用sys-calls(它在很大程度上依赖于操作系统的I / O) . 构建引导加载程序和内核时,重要的是编译器和链接器配置为生成可以在特定内存地址运行的静态链接代码 .

相关问题