本篇文章记录了Marvell Octeon10系列的SDK基本编译方法
Octeon SDK编译
1.服务器前置配置：
安装各种依赖，工具包：
1 | apt install sed build-essential git cpio python3 unzip rsync bc wget texinfo \ |
服务器版本：
Linux OcteonSDK 6.2.0-26-generic
2.快速编译SDK
2.1 安装SDK包
将SDK和roolchain下载到临时的Downloads目录下
然后解压到我们自己的工作目录下。
1 | mkdir ~/work |
解压后目录如下：
1 | ls |
1 | unzip ../doc-<release-id>.zip |
2.2 使用compile.sh文件编译示范
需要指定芯片型号平台进行编译，这里是指定cn10kb的dpu芯片。
【可以这么理解指定特定芯片型号编译出的程序，只能跑在对应的芯片平台上】
1 | cd sdk-base |
这个构建是根据../base-sources-<release-id>中的源文件进行的。最终编译得到的镜像存放在../<platform>-release-output/images目录下。
在本次示例中，它是根据../base-sources-SDK12.23.10目录的源文件进行构建的，编译构建生成的镜像，保存在../cn10kb-release-output/目录下。
其他支持编译的芯片型号，可以用./scripts/ci/compile.sh -l查看
Other supported platforms are shown with ./scripts/ci/compile.sh -l:
cn10ka版本
2.3 构建单个软件包 【Building a Single Package】
略
2.4 ！构建通用扩展【Building a Generic Extension】
如果发行版包括扩展，那么这些扩展也需要与基础SDK一起解压到工作目录中。
1 | cd ~/work |
编译带有switches扩展的sdk:
ext-name表示扩展名,例如：
switches扩展：sdk-ext-switches
vpp扩展：sdk-ext-vpp
pcie扩展：sdk-ext-pcie
1 | # cd sdk-ext-<ext-name> |
查看支持的platform和扩展：
1 | ./scripts/ci/compile.sh -l |
2.5 构建多个通用扩展[Building Multiple Generic Extensions]
构建多个扩展的安装过程与构建单个扩展相同，除了多个扩展被解压到工作目录中：
注：只有通用扩展可以组合在一起编译。带有generic的就是通用扩展。
1.要构建1个附加扩展，请进入其中一个扩展的未打包目录并运行compile.sh，如下所示：
1 | $ cd sdk-ext-<ext-name-1> |
2.对于另外2个扩展，请运行compile.sh，如下所示：
1 | cd sdk-ext-<ext-name-1> |
2.6 构建客户扩展
首先，客户扩展必须与基础SDK一起解压到工作目录中，共三个文件包：基础版本包，工具链包，扩展包：
1 | cd ~/work |
接下来，检查此客户支持哪些构建：
1 | cd sdk-ext-<customer-name> |
2.7 检查SDK版本
cat /proc/octtx_info
3.问题：
1.构建时报错：.config:5: *** 缺失分隔符。 停止。
原因：可能是.config文件中转义字符 \ 在注释行的开头。在标准的配置文件中，注释行不应该使用 \ 开头。
/home/byzoro/work/cn10ka-switches-release-output/build/cpss-SDK12.23.10/.config
编译语法错误：
把srcversion文件中的\去掉
去掉之后，再次构建仍然报错提示游离的,这说明这个文件的内容是make构建的时候写入的，所以要定位在哪里写入的。
找到模块编译的Makefile文件，找到写入头文件的命令。去掉,问题解决。
/home/byzoro/work/cn10ka-switches-release-output/build/cpss-SDK12.23.10/cpssEnabler/mainExtDrv/src/gtExtDrv/linuxNoKernelModule/drivers/_Makefile
Buildroot 指南
开发指南
配置和defconfig片段
defconfig配置文件
Buildroot 配置位于以下目录下的 xxx_defconfig 文件中：
1 | MV_BLDR/sdk-base/configs/ |
1 | ls -a |
1 | ls -a |
defconfig片段
默认的defconfig文件被分为fragment的片段，完整的defconfig被分为几个逻辑部分，称为碎片。这些碎片涵盖了最终defconfig组装所需/可能的所有变量。
碎片列表在$MV_BLDR/sdk-base/configs.mv_frag/frag_list中定义
fragment如何生效的
碎片没有+x执行权限，但被称为“source f_xx”，因此是可执行脚本，执行脚本功能，包括条件语句。configs.mv_frag/f_*碎片由CI脚本./scripts/ci/compile.sh组装成完整的_defconfig文件。
在扩展了<configs.mv_frag>路径后，根据PATH变量收集各个碎片，如下所示
1 | PATH+=$MV_BLDR/sdk-ext-abc/configs.mv_frag:$PATH |
因此，在PATH中发现的第一个“f_xx”片段将被处理（例如，用扩展文件替换base_sdk默认文件“f_xx”）。
根据给定的“目标”名称生成输出配置。生成的完整_defconfig保存在两个地方：
./configs/._defconfig - used internally by Buildroot
**../
/images/_defconfig
** - 用于标准的make方法
_defconfig 还可用于创建辅助文件 $MV_BLDR/
/.build._defconfig。此文件保留了上次编译的完整构建的开始和结束时间。
要生成一个配置文件而不启动构建，请使用–config_only或-c选项调用compile.sh：
1 | ./scripts/ci/compile.sh <....> --config_only ;# or |
注意：
为了生成完整的defconfig文件，compile.sh会调用内部脚本./cfg_frag/generate_defconfig。
生成/解析完整defconfig配置名称（和文件）
完整的defconfig名称是从传递给compile.sh的命令行参数生成的。它由以下部分组成:
build-name
extension-name (可选)
SoC-family (marvell_octeontx, marvell_octeontx2, marvell_armada, marvell_armada3k)
release/devel mode
对于已知的Marvell主板和平台（来自compile.sh –list），SoC系列是已知的并会自动添加。例如，在主板cn10kb上使用扩展switches的发布版本
1 | cd $MV_BLDR/sdk-ext-switches |
主线社区包
根据f_pkg_mainline_x碎片，主线社区包被包含在构建中。可以使用-n选项从提供的碎片列表中选择这些包的一个子集来编译。sh。默认设置是1到4，但可以很容易地更改为较小的集合。例如，要选择集合1、2和3：
1 | ./scripts/ci/compile.sh cn10kb-switches -n3 -r "SDK12.23.10" |
此外，客户可能需要添加（或删除）主线社区公认的BR2_PACKAGE_。这可以通过修改以下碎片之一来完成：
over base_sdk/configs.mv_frag/f_pkg_mainline_custom file modification
over extension/…/f_pkg_mainline_custom
over extension/…/f_pkg_mainline_plat - if this is SoC-family specific
base_sdk/configs.mv_frag/f_pkg_mainline 是影响所有构建的通用修改，因此应与 base_sdk 集成商达成一致。否则，首选方法是修改 f_pkg_mainline_custom 或 f_pkg_mainline_plat。
Marvell内部持续集成（CI）的技巧
创建新的扩展
略
编译时优化
Marvell SDK-cache
Marvell CI 版本构建中设计了一种名为 SDK-cache 的优化方法。它缓存预先下载和预先编译的包，这些包从一个构建到下一个构建不太可能发生变化。
由于 SDK-cache 占实际目标构建的 85% 以上，因此实际目标构建的编译时间可以减少 85% 以上。
SDK缓存方法基于以下内容：
SDK-cache构建输出类似于Marvell-SDK，但没有Marvell特定的包、内核和引导程序。
SDK-cache是所有构建目标通用的包的一个子集。
SDK缓存是一个“目标构建”，只需单独编译。
然后，已构建的SDK缓存（包括配置、对象、输出和中间文件）将被重新用于“真实”的目标构建。
SDK-cache环境包含所有下载的包。
一个真正的目标构建会逐步将自己的包添加到预构建的SDK缓存环境中，并在该环境中进行编译。
SDK-cache 限制
Buildroot 的配置、对象、输出和中间文件都内置了完整路径和用户信息。输出目录也是内置的，因此所有构建（缓存和其他）都应该构建到名为“output”的同一文件夹中。
这意味着在此环境中预构建的SDK缓存只能在同一用户和同一路径下用于其他构建。
Marvell CI 夜间自动化构建在用户“jenkins”下运行，路径为 </home/jenkins/workspace/nightly-devel>。它也在 Docker 容器内运行，因此满足这些要求。
然而，使用可共享的Build-Server的用户无法以简单的方式使用SDK-cache。
如何利用SDK的缓存cache
全局目录变量：
1 | TOPDIR : $MV_BLDR/buildroot |
Marvell CI Nightly Automation Build 在用户“jenkins”下运行，路径为 /home/jenkins/workspace/nightly-devel。它也在 Docker 容器内运行，因此满足这些要求。
如何创建和使用缓存?
1.构建缓存，这里是构建OcteonTX2 芯片类型的缓存
注：SDK-cache支持三种类型
otx2 (octeontx/otx uses the same otx2 cache)
armada
armada3
1 | export MV_BLDR=/home/jenkins/workspace/nightly-devel |
替换成我们的目录就是：
1 | export MV_BLDR=/home/bozoro/work/nightly-devel |
注意：如果是发行版本，或者SDK扩展版，注意输出目录
1 | ./scripts/ci/compile.sh cn10kb-switches -d -r SDK12.23.10-PR6 -s |
原来工作目录下是：
1 | byzoro@OcteonSDK:~/work$ ls |
执行完毕之后：
现在构建缓存成功之后,多了三个文件：
sdk_cache-cn10k-11685eb4.dl.tar
sdk_cache-cn10k-11685eb4.out.tar
output
现在需要新建一个nightly-devel作为缓存目录,path为/home/bozoro/work/nightly-devel
2.将“sdk_cache-otx2-7ba40650.tar”复制到一个文件夹中，以便其他版本进一步重复使用
1 | cp ../sdk_cache-otx2-7ba40650.tar /path/to/my-saved-caches |
即：
1 | cp ../sdk_cache-cn10k-11685eb4.dl.tar /home/byzoro/work/nightly-devel/to/my-saved-caches/ |
3.新的构建，使用别的构建生成的缓存
对于新构建，可以将缓存复制到新的安装目录（MV_BLDR）中，以加快构建时间。按照building_development_images中的步骤进行操作，直到准备好编译为止。
1 | MV_BLDR/output and $MV_BLDR/buildroot/dl 然后目录就会被还原，就可以继续下面的构建 |
重新使用以前版本的SDK缓存
再次构建缓存：
1 | ./scripts/ci/compile.sh cn10kb-switches -d -r SDK12.23.10-PR6 -s |
当新版本缓存的defconfig与具有相同sdk-cache-ID的上一版本相同时，构建将绕过并显示以下消息：
CCACHE【禁用】
Buildroot 提供了对“编译器缓存”的内置优化功能。编译器缓存是一种技术，用于存储编译过的程序或库的中间结果，以便在后续编译时重用这些结果，从而加快编译速度。
此方法有一个限制 - 它依赖于编译工具链，但在工具链更改时，它不会检查也不会更新缓存。
一些用户/开发人员可以从使用这种优化方法中受益。然而，用户构建中主要的耗时任务（高达整个构建时间的50%）是从外部存储库下载软件包源代码。
这种方法不适用于在Docker容器内运行并始终从头开始的Marvel CI-Automation。
官方版本中已禁用CCACHE Buildroot功能。开发人员可以使用Buildroot手册中的概念自行启用并尝试
【注意事项】：
Buildroot Work-directory ($MV_BLDR)
$MV_BLDR=/home/byzoro/work
1.构建根目录：work目录下的文件名字不能随意更改，且所有操作必须是在同一个user下操作的。
2.在 MV_BLDR 迁移后始终清理环境。
要清理MV_BLDR，就要清除cn10kb-switches-release-output目录
3.使用-d选项使用默认的输出目录。
“-d”参数强制构建使用MVBLDR/output目录，而不是−−output。使用“−d”时，所有变体的构建都在相同的MV_BLDR/output下完成。因此：
一旦将包 ABC 下载到 $MV_BLDR/buildroot/dl/ABC 中，它就不会更新，当源 GIT 上下文更改时，应手动删除以进行更新。
Buildroot 检查每个包的依赖关系，而不是每个文件，一旦在 $MV_BLDR/output/build/ABC 中编译了包 ABC，它就不会在代码更改时自动重新编译，应该手动删除以进行重新构建。
可能需要清理TARGET和STAGING文件夹，但此类清理的程序不在本文档范围内。
Buildroot output folder content
Buildroot构建过程中产生的所有输出文件和目录
Firemare and Boot
Early Boot Firmware (EBF) User Guide
早期固件启动指导手册
Program Board Manufacturing Data
Set tracing level for EBF and ATF
Set mode of Ethernet ports
Set mode of PCIe SERDES
按B进入启动菜单
Setup Menu
要进入设置菜单，请按 B 键中断 EBF 的正常启动流程。这将显示启动菜单。从启动菜单中，选择 S 进入主设置菜单，显示以下内容之一（基于平台）
CN10xxx:
1 | Setup |
PCIE EP Security Settings
Marvell主机实用程序可能需要更改以下PCIE EP安全设置
主机内存访问启用
主机流 ID 设置
要访问PCIE EP Security设置菜单，首先进入Setup菜单。然后根据平台选择以下选项，浏览菜单并进入PCIE EP Security设置菜单
CN10xxx:
1 | "P) PCIe Configuration" |
在这里，安全菜单应该显示:
1 | ================================= |
首先，选择 ‘Allow PCIe Host to Access Octeon Memory’ and 输入1:
1 | Choice: A |
然后选择 ‘Host Stream IDs for PEM0’ entry 并 输入之前确定的 Host Stream ID ：
1 | Choice: 0 |
分别输入每个流ID；无需输入之前显示的当前值
在输入所有流ID后，选择“返回主菜单”选项返回设置菜单。可能需要重复选择，直到显示设置菜单。
最后，从“设置”菜单中选择“保存设置并退出”，这将保存设置并重新启动EBF
1 | S) Save Settings and Exit |
之后，应正确配置Marvell Host Utilities，使其能够访问执行Linux的适配器。
Config options
所有的配置选项都会成为设备树（device tree）下“cavium,bdk”节点的属性。这些可以在板子的DTS（Device Tree Source，设备树源文件）文件中设置；一些配置也可以从设置菜单中设置。如果一个配置在两个地方都被设置了，那么设置菜单中设置并保存的值优先级更高。
- 本文作者： CoderSong
- 本文链接： https://jack-song-gif.github.io/2024/03/20/Marvell-SDK编译/
- 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！