资料下载
使用Genode控制Zybo Z7 GPIO - 第2/2部分
陈敏
分享资料个
描述
在第一部分中，我通过 GPIO 控制器启用了对板载按钮、开关和 LED 的控制。在这一部分中，我将实现一个自定义 IP 核来控制 Zybo Z7-20 (Z7-10) 上两个（一个）RGB LED 的颜色和亮度。
在这个故事的结尾，您会找到快速设置说明，以从源代码存储库中复制完整的演示。
概念
RGB LED 实际上由三个单独的 LED 组成：红色、绿色和蓝色。每种颜色都可以通过不同的引脚打开/关闭。因此，通过改变每个 LED 的亮度，我们基本上可以混合任何颜色。但是，如果我们只有一个开/关开关，我们如何实际调整亮度呢？答案称为 PWM（脉宽调制）。当以快于大约 50Hz 的速度打开和关闭 LED 时，人眼无法检测到任何闪烁。因此，通过改变开启时间和关闭时间之间的比率，我们能够欺骗人眼感知不同的亮度级别。
尽管现代 CPU 的速度肯定足以单独执行这项工作，但要确保在高 CPU 负载下的正确时序可能会变得棘手。即使我们设法满足 PWM 的严格时序要求，其他应用程序也需要频繁抢占。幸运的是，我们还有可编程逻辑 (PL)，我们可以为其配备定制 IP 核，以完美无缺地执行 PWM，从而将所有 CPU 资源留给更有趣的计算。
在开始实际实施之前，让我说明一下我想要实现的目标：
该图显示了用于控制单个 RGB LED 的 my IP 核的基本思想。Xilinx 在ug1118方面提供了更详细的指南。
有了这些背景信息，我就能够通过Tool → Create and Package New IP创建我的自定义 IP 核。在对话框中，我选择了 Create a new AXI4 peripheral因为我想实现一个 MMIO 接口。在最后的对话中，我选择了编辑 IP作为下一步。
Vivado 的 IP 打包工具已经负责生成所有样板代码。默认情况下，它实现了一个带有四个 32 位寄存器的 MMIO 接口，这正是我控制两个 RGB LED 的颜色和亮度所需要的。
为了实现 RGB 模块，我添加了一个 Verilog 源文件并开始实现一个用于驱动单个 RGB LED 引脚的模块：
module rgbled(
output reg [2:0] rgb,
input wire [6:0] brightness,
input wire [7:0] red,
input wire [7:0] green,
input wire [7:0] blue,
input wire clk
);
// [...] see below
endmodule
该rgbled模块得到一个三位输出信号rgb（每种颜色一位）。此外，它还有四个用于亮度、红色、绿色和蓝色值的输入信号以及一个时钟输入。如果您是 Verilog 的新手并且想知道 和 之间的区别reg，wire我可以向您推荐本教程。简而言之，一个reg信号能够存储一些状态，而一个wire仅仅是一个连接。
作为模块实现的第一部分，我添加了一个循环计数器，当它达到某个最大值时，它会将自身重置为 0：
module rgbled(
// [...] see above
reg [14:0] counter;
wire [14:0] max_cycles;
always @(posedge clk) begin
if (counter < max_cycles) begin
counter <= counter + 1;
end
else begin
counter = 0;
end
end
// [...] see below
endmodule
我决定采用 0 到 100 之间的亮度值，以便max_cycles在 255（亮度 100）和 25500（亮度 1）之间线性缩放，亮度为 0 的特殊情况：
module rgbled(
// [...] see above
assign max_cycles =
brightness > 100 ? 255
: (brightness == 0 ? 0
: 255 * 100 / brightness);
// [...] see below
endmodule
这使得实现开/关切换逻辑变得非常简单：
module rgbled(
// [...] see above
always @(posedge clk) begin
if (max_cycles > 0) begin
rgb[0] <= red > counter ? 1 : 0;
rgb[1] <= blue > counter ? 1 : 0;
rgb[2] <= green > counter ? 1 : 0;
end
else begin
rgb <= 3'b000;
end
end
endmodule
这就完成了rgbled模块，但是，它仍然需要在自定义 IP 内核中实例化。创建 IP 核时，Vivado 生成了两个 Verilog 文件。我确定后缀为S00_AXI.v的文件是 MMIO 模块，另一个文件是顶层模块。查看 MMIO 模块，我注意到文件顶部有一条注释“用户在此处添加端口”，我在其中为输出信号添加了这两行：
// Users to add ports here
output wire [2:0] led0,
output wire [2:0] led1,
// User ports ends
// Do not modify the ports beyond this line
在文件的底部，我找到了注释“在此处添加用户逻辑”并插入了我的rgbled模块的两个实例。查看自动生成的实现，我发现 MMIO 寄存器被命名为slv_reg0, slv_reg1,slv_reg2以及slv_reg3. 因此，我只需要决定哪个寄存器中的哪些位。用于 RGB 和亮度值。我最终得到了这些实例化：
// Add user logic here
rgbled led0_control (
.clk (S_AXI_ACLK),
.red (slv_reg0[23:16]),
.blue (slv_reg0[15:8]),
.green (slv_reg0[7:0]),
.brightness (slv_reg1[6:0]),
.rgb (led0)
);
rgbled led1_control (
.clk (S_AXI_ACLK),
.red (slv_reg2[23:16]),
.blue (slv_reg2[15:8]),
.green (slv_reg2[7:0]),
.brightness (slv_reg3[6:0]),
.rgb (led1)
);
// User logic ends
由于我修改了 MMIO 模块的端口，我还在顶层文件中添加了两个类似的输出端口，并将它们传递给 MMIO 模块的实例化。
完成这些更改后，我注意到Package IP视图发生了一些变化。首先，文件组部分不再有绿色勾号。查看此部分并遵循 Vivado 的合并更改建议解决了此问题。端口和接口部分提供了一个类似的合并向导。Vivado 自动检测到我之前添加的led0和led1端口。本节不需要手动调整，但我了解到我能够定义某些类型的接口并将端口映射到这些接口。因此，人们可以将信号分组到一个共同的分组中，并协助 Vivado 的自动连接魔法。
我跳过了接口定义，进入了Review and Package部分并打包了我的 IP 核。我回到我的块设计并将新封装的 IP 内核添加到设计中，运行自动连接向导并将led0端口设置led1为外部（与之前对GPIO_0接口所做的一样，请参见第 1 部分）。MMIO 设备的地址由 Vivado 自动分配，但可以在打开块设计后在地址编辑器中更改。在重新生成比特流之前，我取消了约束文件中 RGB LED 行的注释，并插入了相应的信号名称（led0_0[0]toled0_0[2]和led1_0[0]to led1_0[2]）。
请注意，如果您想稍后编辑 IP 核，您可以右键单击模块设计中的核并选择Edit in IP Packager 。
最终，我为这个新设计生成了比特流，并使用File → Export → Export Bitstream File导出结果。
使用自定义 IP 内核
有了新的比特流，我实现了一个zybo_gpio_demo_rgb组件来测试 MMIO 接口。该组件使用按钮 0 到 3 循环显示两个 RGB LED 的某些颜色和亮度值。您可以在genode-zynq 存储库中找到代码。如果您遵循了第 1 部分，那么其中的大部分内容是不言自明的。然而，让我简要说明如何访问 MMIO 接口：
#include
/* [...] */
class Demo::Rgb_leds : public Platform::Device::Mmio
{
private:
struct Led : Genode::Mmio {
struct Color : Register<0x0, 32> { };
struct Brightness : Register<0x4, 32> { };
void color(uint32_t c) {
write(c); }
void brightness(uint32_t b) {
write(b); }
};
Led led0 { (addr_t)local_addr<void>() };
Led led1 { (addr_t)local_addr<void>() + 0x8 };
public:
Rgb_leds(Platform::Device &device)
: Platform::Device::Mmio(device)
{ }
void led0_color(uint32_t c) {
led0.color(c); }
void led0_brightness(uint32_t b) {
led0.brightness(b); }
void led1_color(uint32_t c) {
led1.color(c); }
void led1_brightness(uint32_t b) {
led1.brightness(b); }
};
在 Genode 中，可以通过寄存器框架轻松访问 MMIO 接口。我们只需要继承Platform::Device::Mmio（或Genode::Mmio）并定义几个寄存器。Platform::Device::Mmio从平台驱动程序获取映射的设备地址，而Genode::Mmio期望地址作为构造函数参数。在这里，我使用后者来定义Led包含单个 LED的Color和寄存器的结构。Brightness该类的模板参数Register指定其偏移量和访问宽度（以位为单位）。可以轻松读取寄存器。用模板方法编写，read()如write()和 中Led::color()所示Led::brightness()。然后，我使用 的方法实例化该Led结构两次，以获取映射的设备地址。local_address()Platform::Device::Mmio
为了将新实现的组件添加到 GPIO 演示中，我在run/zybo_gpio_demo.run脚本中添加了以下启动节点：
<start name="zybo_gpio_demo_rgb">
<resource name="RAM" quantum="2M"/>
<route>
<service name="Pin_control"> <child name="zynq_pin_drv"/> service>
<service name="Pin_state"> <child name="zynq_pin_drv"/> service>
<service name="IRQ"> <child name="zynq_pin_drv"/> service>
<service name="Platform"> <child name="platform_drv"/> service>
<service name="ROM"> <parent/> service>
<service name="CPU"> <parent/> service>
<service name="PD"> <parent/> service>
<service name="LOG"> <parent/> service>
route>
start>
此外，我修改了引脚驱动程序配置如下：
<config>
<in name="Btn4" bank="1" index="18" irq="rising"/>
<in name="Btn5" bank="1" index="19" irq="rising"/>
<out name="Led4" bank="0" index="7" default="on"/>
<policy label="zybo_gpio_demo_mio -> Btn4" pin="Btn4"/>
<policy label="zybo_gpio_demo_mio -> Btn5" pin="Btn5"/>
<policy label="zybo_gpio_demo_mio -> Led4" pin="Led4"/>
<in name="Sw0" bank="2" index="0" irq="edges"/>
<in name="Sw1" bank="2" index="1" irq="edges"/>
<in name="Sw2" bank="2" index="2" irq="edges"/>
<in name="Sw3" bank="2" index="3" irq="edges"/>
<out name="Led0" bank="2" index="8" default="off"/>
<out name="Led1" bank="2" index="9" default="off"/>
<out name="Led2" bank="2" index="10" default="off"/>
<out name="Led3" bank="2" index="11" default="off"/>
<policy label="zybo_gpio_demo_sw -> Sw0" pin="Sw0"/>
<policy label="zybo_gpio_demo_sw -> Sw1" pin="Sw1"/>
<policy label="zybo_gpio_demo_sw -> Sw2" pin="Sw2"/>
<policy label="zybo_gpio_demo_sw -> Sw3" pin="Sw3"/>
<policy label="zybo_gpio_demo_sw -> Led0" pin="Led0"/>
<policy label="zybo_gpio_demo_sw -> Led1" pin="Led1"/>
<policy label="zybo_gpio_demo_sw -> Led2" pin="Led2"/>
<policy label="zybo_gpio_demo_sw -> Led3" pin="Led3"/>
<in name="Btn0" bank="2" index="4" irq="edges"/>
<in name="Btn1" bank="2" index="5" irq="edges"/>
<in name="Btn2" bank="2" index="6" irq="edges"/>
<in name="Btn3" bank="2" index="7" irq="edges"/>
<policy label_suffix="zybo_gpio_demo_rgb -> Btn0" pin="Btn0"/>
<policy label_suffix="zybo_gpio_demo_rgb -> Btn1" pin="Btn1"/>
<policy label_suffix="zybo_gpio_demo_rgb -> Btn2" pin="Btn2"/>
<policy label_suffix="zybo_gpio_demo_rgb -> Btn3" pin="Btn3"/>
config>
为了进行简短的测试运行，我通过（临时）将以下行添加到board/zynq_zybo_z7/devices文件来让平台驱动程序了解新的 MMIO 设备：
<device name="rgbleds" type="my_rgbleds">
<io_mem address="0x43c00000" size="0x1000"/>;
device>
为了能够访问这个 MMIO 设备，我还在 platform-driver 配置中添加了相应的策略：
<policy label="zybo_gpio_demo_rgb -> ">
<device name="rgbleds"/>
policy>
将比特流文件复制到我的 SD 卡后，我可以使用 LED 下方的四个按钮更改两个 RGB LED 的颜色和亮度。但是，由于zybo_gpio_demo_rgb使用的 MMIO 设备只有在我的自定义比特流被加载时才可用，所以我更愿意在运行时使用 Genode 执行比特流加载过程，以便我可以在比特流加载后自动启动相应的软件组件.
在运行时切换比特流
在本节中，让我们看看如何在运行时在 Genode 中加载比特流。仅仅对 FPGA 进行重新配置非常简单，但它对定制平台设备的可用性也有影响。为了适应这个用例，我创建了仓库存档pkg/drivers_fpga-zynq 。
如上图所示，pkg/drivers_fpga-zynq子系统需要两个 ROM 会话（devices_manager.config和policy ）以及一个文件系统会话。作为回报，它通过提供平台服务充当平台驱动程序。策略ROM 包含此 GPIO 演示的平台驱动程序配置：
<report devices="yes"/>
<policy label_suffix="zynq_pin_driver -> ">
<device name="gpio0"/>
policy>
<policy label_suffix="zybo_gpio_demo_rgb -> ">
<device name="rgbleds"/>
policy>
节点指示内部平台驱动程序在其状态发生变化时生成设备报告。Zynq 驱动程序管理器使用此报告来确定特定设备何时可用。因此，Zynq Driver Manager 可能会生成一个新的init.config来启动相应的驱动程序组件。驱动程序组件和相应的设备依赖项在管理器的配置中指定。为了在my_rgbleds设备可用后启动zybo_gpio_demo_rgb ，我使用以下配置：
<config>
<driver name="zybo_gpio_demo_rgb" device="my_rgbleds">
<binary name="zybo_gpio_demo_rgb"/>
<resource name="RAM" quantum="2M"/>
driver>
config>
devices_manager.config提供比特流及其实现的设备的规范。我们可以让pkg/drivers_fpga-zynq子系统知道什么比特流可以使用什么设备，而不是像我在上一节中那样将rgbleds设备添加到静态设备 ROM。对于我之前生成的两个比特流，我使用以下devices_manager.config 。
<config>
<bitstream name="zybo_z720_rgb-bitstream.bit">
<devices>
<device name="rgbleds" type="my_rgbleds">
<io_mem address="0x43c00000" size="0x1000"/>;
device>
devices>
bitstream>
<bitstream name="zybo_z720_gpio-bitstream.bit"/>
config>
请注意，我将两个 ROM（devices_manager.config和policy ）打包到一个raw/zybo_gpio_demo存档中。
pkg/drivers_fpga-zynq子系统最终从其文件系统会话中读取用户提供的比特流。此外，负责比特流加载的内部fpga_drv组件从/config文件获取其配置。因此，该文件指定应将哪些比特流加载到 FPGA 中，例如：
<config>
<bitstream name="zybo_z720_rgb-bitstream.bit"/>
config>
通过简单地更改此文件的内容，我们可以在比特流之间切换。至此，zybo_gpio_demo_mio组件为什么要生成状态报告就清楚了。通过在run/zybo_gpio_demo.run脚本中添加一个ROM filter组件，我可以轻松实现码流切换：
<start name="rom_filter">
<resource name="RAM" quantum="1M"/>
<provides>
<service name="ROM"/>
provides>
<route>
<service name="ROM" label="state"> <child name="report_rom"/> service>
<service name="ROM"> <parent/> service>
<service name="CPU"> <parent/> service>
<service name="PD"> <parent/> service>
<service name="LOG"> <parent/> service>
route>
<config>
<input name="state">
<attribute name="value"/>
input>
<output node="config">
<node type="bitstream">
<if>
<has_value input="state" value="yes"/>
<then>
<attribute name="name"
value="zybo_z720_rgb-bitstream.bit"/>
then>
<else>
<attribute name="name"
value="zybo_z720_gpio-bitstream.bit"/>
else>
if>
node>
output>
config>
start>
当然，我还需要实例化上图中所示的所有组件。让我们从用pkg /drivers_fpga-zynq子系统替换platform_drv开始：
<start name="platform_drv" caps="1000" managing_system="yes">
<binary name="init"/>
<resource name="RAM" quantum="24M"/>
<provides> <service name="Platform"/> provides>
<route>
<service name="ROM" label="config">
<parent label="drivers.config"/>
service>
<any-service> <parent/> <any-child/> any-service>
route>
start>
接下来，我添加了 Zynq 驱动程序管理器、动态驱动程序子系统和 VFS 服务器：
<start name="zynq_driver_manager">
<resource name="RAM" quantum="2M"/>
<route>
<service name="ROM" label="devices">
<child name="report_rom"/>
service>
<any-service> <parent/> <any-child/> any-service>
route>
<config>
<driver name="zybo_gpio_demo_rgb" device="my_rgbleds">
<binary name="zybo_gpio_demo_rgb"/>
<resource name="RAM" quantum="2M"/>
driver>
config>
start>
<start name="dynamic_drivers" caps="500">
<binary name="init"/>
<resource name="RAM" quantum="5M"/>
<route>
<service name="ROM" label="config">
<child name="report_rom"/>
service>
<service name="IRQ"> <child name="zynq_pin_drv"/> service>
<any-service> <parent/> <any-child/> any-service>
route>
start>
<start name="vfs">
<resource name="RAM" quantum="8M"/>
<provides><service name="File_system"/>provides>
<route>
<service name="ROM" label="fpga.config">
<child name="rom_filter"/>
service>
<any-service> <parent/> any-service>
route>
<config>
<vfs>
<rom name="config" label="fpga.config"/>
<rom name="zybo_z720_gpio-bitstream.bit"/>
<rom name="zybo_z720_rgb-bitstream.bit"/>
vfs>
<default-policy root="/" writeable="no"/>
config>
start>
VFS 组件通过文件系统会话传送由 ROM 过滤器组件生成的比特流和fpga.config ROM。
最后，我将import_from_depot行更新如下：
import_from_depot [depot_user]/src/[base_src] \
[depot_user]/src/init \
[depot_user]/pkg/drivers_fpga-zynq \
[depot_user]/src/driver_manager-zynq \
[depot_user]/src/report_rom \
[depot_user]/src/rom_filter \
[depot_user]/src/vfs \
[depot_user]/raw/zybo_gpio_demo \
[depot_user]/src/zynq_pin_drv \
[depot_user]/raw/[board]-devices
试一下修改后的运行脚本，我得到了这个输出：
build/arm_v7a #> make run/zybo_gpio_demo BOARD=zynq_zybo_z7 KERNEL=hw
...
[init -> report_rom] Warning: no policy defined for
label 'zynq_driver_manager -> devices'
[init -> report_rom] Warning: no valid policy for ROM request
'zynq_driver_manager -> devices'
[init -> report_rom] Warning: no policy defined for
label 'dynamic_drivers -> config'
[init -> report_rom] Warning: no valid policy for ROM request
'dynamic_drivers -> config'
[init -> report_rom] Warning: no policy defined for
label 'rom_filter -> state'
[init -> report_rom] Warning: no valid policy for ROM request
'rom_filter -> state'
...
当然，我忘记了将策略定义添加到report_rom配置中，因此我为每个记录的标签添加了一个策略节点：
report="zybo_gpio_demo_mio -> state"/>
label="zynq_driver_manager -> devices"/>
label="dynamic_drivers -> config"/>
运行脚本的另一个旋转产生以下输出：
[init -> vfs] Error: ROM-session creation failed (ram_quota=6144,
cap_quota=3, label="zybo_z720_gpio-bitstream.bit")
[init -> vfs] Error: Could not open ROM session for
"zybo_z720_gpio-bitstream.bit"
[init -> vfs] Error: failed to create VFS node
[init -> vfs] Error: name="zybo_z720_gpio-bitstream.bit"
[init -> vfs] Error: ROM-session creation failed (ram_quota=6144,
cap_quota=3, label="zybo_z720_rgb-bitstream.bit")
[init -> vfs] Error: Could not open ROM session for
"zybo_z720_rgb-bitstream.bit"
[init -> vfs] Error: failed to create VFS node
[init -> vfs] Error: name="zybo_z720_rgb-bitstream.bit"
我还没有提供比特流文件。对于一个简短的测试，我可以简单地将文件复制到build/arm_v7a/bin并将它们添加到该build_boot_image行。然而，我想到了另一个解决方案，它使用Goa ，一个基于命令行的工作流工具，用于为 Genode OS 框架开发应用程序。
为 Genode 构建和打包比特流
为了以仓库档案的形式提供比特流，我添加了对 Goa 的 Vivado 支持。幸运的是，Vivado 提供了以 tcl 脚本形式导出项目的命令，允许重新创建项目。在本节中，我将重点介绍如何使用 Goa 的 Vivado 支持。
首先，我需要导出要打包的 Vivado 项目。因此，在 Vivado 的 TCL 控制台中，我输入了以下命令：
write_project_tcl -paths_relative_to /home/johannes/vivado_workspace /tmp/vivado.tcl
该-paths_relative_to参数是必不可少的，因为它将源文件的路径转换为相对路径。在我的goa-pkgs 存储库中，我创建了子目录zynq/zybo_z720_rgb-bitstream/以创建一个新的 Goa 项目并将vivado.tcl复制到新的 Goa 项目的src/子目录中。通过检查 tcl 文件，我们可以获得所需源文件的列表。在我的 tcl 文件中，以下几行引起了我的注意：
proc checkRequiredFiles { origin_dir} {
set status true
set files [list \
"[file normalize "$origin_dir/xilinx/project_2/project_2.srcs/constrs_1/imports/Downloads/Zybo-Z7-Master.xdc"]"\
]
foreach ifile $files {
if { ![file isfile $ifile] } {
puts " Could not find local file $ifile "
set status false
}
}
set paths [list \
"[file normalize "$origin_dir/../../[file normalize "$origin_dir/xilinx/ip_repo/rgbled_1.0"]"]"\
]
foreach ipath $paths {
if { ![file isdirectory $ipath] } {
puts " Could not access $ipath "
set status false
}
}
return $status
}
该checkRequiredFiles过程提供了关于我必须将哪些源文件复制到我的 Goa 项目中的第一个提示。在这种情况下，它列出了约束文件以及我的自定义 IP 内核的路径。
请注意，Goa 会将src / 目录中的所有文件镜像到存档的构建目录中。$origin_dir此外，在重新创建 Vivado 项目时，它将使用构建目录。因此，必须将所需文件及其相应的相对路径复制到src / 目录中。
通过向我的 Goa 项目添加一个工件文件，我进一步告诉 Goa 将什么构建工件包含到bin//zybo_z720_rgb-bitstream存档中。由于 Goa 将比特流写入以模式命名的文件中.bit，因此工件文件必须具有以下内容：
zybo_z720_rgb-bitstream.bit
此外，由于 bin 存档总是与特定的 CPU 体系结构相关联，因此我arm_v7a通过添加具有以下内容的.goarc来设置目标体系结构：
set arch arm_v7a
set jobs 1
请注意，我还将作业数限制为 1，以减少 Vivado 的资源消耗。有了这些先决条件，产生了以下错误：goa build
goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
Error: tool-chain prefix is not defined
此消息暗示在 Goa 中尚无对arm_v7a的内置支持。因此，我通过将以下行添加到.goarc文件来手动定义工具链前缀：
set cross_dev_prefix "/usr/local/genode/tool/current/bin/genode-arm-"
现在，goa build抱怨缺少 vivado 二进制文件：
goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
...
Error: build-directory creation via vivado failed:
couldn't execute "vivado": no such file or directory
当然，我忘记了Vivado环境的源码。如下修复此问题后，Goa 能够在几分钟内构建比特流：
goa-pkgs/zynq/zybo_z720_rgb-bitstream$ source /tools/Xilinx/Vivado/2021.1/settings64.sh
goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
...
[zybo_z720_rgb-bitstream:vivado] 10 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
[zybo_z720_rgb-bitstream:vivado] write_bitstream completed successfully
[zybo_z720_rgb-bitstream:vivado] write_bitstream: Time (s): cpu = 00:00:11 ; elapsed = 00:00:13 . Memory (MB): peak = 3202.781 ; gain = 451.625 ; free physical = 1133 ; free virtual = 2434
[zybo_z720_rgb-bitstream:vivado] INFO: [Common 17-206] Exiting Vivado at Thu Oct 6 15:35:31 2022...
构建成功后，我准备尝试goa export –depot-user jschlatow。输出提醒我添加许可证和版本文件。添加这些文件后，我准备导出和发布 depot 存档。
使用打包的比特流
最后遗漏的一块拼图是将以下参数添加到run/zybo_gpio_demo.run中的import_from_depot过程。
import_from_depot ...
jschlatow/src/zybo_z720_rgb-bitstream/2022-09-29 \
jschlatow/src/zybo_z720_gpio-bitstream/2022-09-27 \
...
现在，在运行时make run/zybo_gpio_demo，我可以使用按钮 4 和 5 在两个比特流之间切换。
从源代码复制演示
要重现演示，您可以在 genode-zynq 存储库中找到完整的运行脚本和源文件。我假设您已经克隆了主 genode 存储库和 genode-zynq 存储库（请参阅Genode 101：Zybo Z7 入门）。这也意味着您已经为arm_v7a创建了一个构建目录。
作为先决条件，您需要下载比特流档案。这是通过必须从基因节点工作树中运行的以下两个命令来实现的。
genode$ ./tool/depot/download jschlatow/bin/arm_v7a/zybo_z720_rgb-bitstream/2022-09-29
genode$ ./tool/depot/download jschlatow/bin/arm_v7a/zybo_z720_gpio-bitstream/2022-09-27
现在，您可以按如下方式执行运行脚本：
genode$ make -C build/arm_v7a run/zybo_gpio_demo BOARD=zynq_zybo_z7
如果您已经按照说明进行了 TFTP 引导，则只需按下 Zybo 板上的重置按钮并等待系统引导新建的映像。或者，您将之前准备的 micro SD 卡的uImage文件替换为build/arm_v7a/var/run/zybo_gpio_demo/uImage。系统启动后，您可以使用按钮 4 和 5 切换比特流。这两个比特流都允许您使用四个开关来控制它们旁边的 LED。然而，只有在加载zybo_z720_rgb-bitstream时才能控制 RGB LED 。按钮 0 到 3 用于循环显示不同的颜色和亮度设置。
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。 举报投诉
- 相关下载
- 相关文章
