- 说明
- 点击数：11513
2021-10-31
2.27 MB
7,024内容节选
第一章 Wind River........................................................... 4
1.1 风河系统公司简介 ..................................................... 4
1.2 实时操作系统 Vxworks 简介............................................. 4
第二章 Tornado.............................................................. 6
- 说明
- 点击数：4980
前段时间抽空做了vxWorks7.0下的基于zynq的boot程序，在此做个总结。
vxworks7.0支持三种不同的boot程序：第一种uboot，第二种vxworks6.9.x以上的bootloader，第三种bootapp，关于uboot的创建方法在前面的博文中已经提到过，bootloader6.9的话，因为我不在使用6.9的版本，所以在此也就不做介绍，今天我们来谈一谈vxworks7.0下bootapp的创建方法。
首先，创建VSB工程，在创建VSB工程时一定要选择up类型创建，具体的创建方法，做过vxworks7.0的都会，在这里就不多做介绍了。
其次创建VIP工程，使用-profile PROFILE_BOOTAPP属性创建VIP工程，在VIP工程中添加组件INCLUDE_STANDALONE_DTB，使用嵌入式的vxWorks,让设备树编译到vxWorks中去。切记不能包含组件INCLUDE_PATCH_STANDALONE_DTB
接着增加boot参数的存储配置，如果有独立的基于IO系统的eeprom专门用于存储boot参数，包含组件INCLUDE_BOOTAPP_NVRAM_SUPPORT，设置其属性值：
prj vip parameter set BOOTAPP_GENERIC_NVRAM_NAME \"/eeprom/0\"
prj vip parameter set BOOTAPP_GENERIC_NVRAM_OFFSET 0x0
prj vip parameter set BOOTAPP_GENERIC_NVRAM_SIZE 0x100
其中BOOTAPP_GENERIC_NVRAM_NAME必须是你devs看到的IO系统的flash设备名称。其他参数是flash设备的大小和偏移地址。
在这里我使用的是S25FL265S的QSPIflash，总大小为0x2000000，其中前0x800000为boot和设备的一些配置参数，其余的用于挂接文件系统，存放系统的启动镜像文件，所以在0x800000-0x10000位置存储boot参数，用于设备启动时参数的修改，修改bsp文件
- 说明
- 点击数：1484
一直以来想看看新的VxWorks 7.0有什么变化，最近抽了一段时间做了一个基于zedboard的VxWorks的操作系统镜像，刚开始就被很多新的问题困扰了很久，首先是uboot，VxWorks7不再有bootloader，变成了全新的uboot支持，有的CPU增加了一个VxBL作为系统启动引导，但是官网推荐用U-Boot引导启动，如何编译一个uboot，可以参考BSP包里面的target.ref，也可以从官网下载U-Boot源码，修改支持自己的处理器，然后重新编译，下面是关于zedboard的u-boot编译：
1、需要一台装有Linux系统或Windows系统装有Linux虚拟机的电脑，系统为Ubuntu；
2、进入Ubuntu系统，按Ctrl+Alt+T调出Terminal终端。输入sudo passwd root，会要求输入用户密码，然后重置root的密码，这里密码都不会显示。重置完后输入su root，再输入刚刚重置的root密码即可进入root
这里要说明很关键的一点，一定要把目录设置好。
3、在root目录下，输入mkdir /zed，在zed下创建tool，将下载的xilinx-2011.09-50-arm-xilinx-linux-gnueabi.bin拷贝到tool目录下。
输入如下命令：
cd /root/zed/tool
然后执行如下命令：
- 说明
- 点击数：1689
最近更换mpc8313的phy芯片，由原来的lxt972Phy更换为DP83849I，在此记录下本人在驱动开发过程中的点滴记录，以备日后查询，基于vxbus的网络驱动，vxBus驱动的注册遵循一致的方法，驱动接口为：
device_method_t dp83849PhyMethods[] =
{
DEVMETHOD(miiModeGet, dp83849PhyModeGet),
DEVMETHOD(miiModeSet, dp83849PhyModeSet),
DEVMETHOD(vxbDrvUnlink, dp83849PhyInstUnlink),
{ 0, 0 }
};
struct drvBusFuncs dp83849PhyFuncs =
{
dp83849PhyDevInstInit, /* devInstanceInit */
dp83849PhyDevInstInit2, /* devInstanceInit2 */
dp83849PhyDevInstConnect /* devInstanceConnect */
};
struct vxbDevRegInfo dp83849PhyDevRegistration =
{
NULL, /* pNext */
VXB_DEVID_DEVICE, /* devID */
VXB_BUSID_MII, /* busID = MII Bus */
VXBUS_VERSION_3, /* busVer */
"dp83849Phy", /* drvName */
&dp83849PhyFuncs, /* pDrvBusFuncs */
dp83849PhyMethods, /* pMethods */
dp83849PhyProbe /* devProbe */
};
void dp83849PhyRegister(void)
{
vxbDevRegister (&dp83849PhyDevRegistration);
return;
}
要编写驱动，主要去实现上面模块中的相关功能，首先编写dp83849PhyProbe，在函数中识别flash的ID，编写其他相关的函数，接下来在sysLib.c中注册系统驱动
- 说明
- 点击数：1364
如果你是从一个更早的VxWorks版本转到VxWorks 7的话，你可能想知道：我该如何编译一个bootrom呢？本文将解释VxWorks 7的启动机制是如何变化的，针对基于客制化硬件的工程来说意味着什么？如果你想从更早的VxWorks版本的BSP升级的话，你需要阅读以下内容。
VxWorks 4/5/6的启动过程
在使用VxWorks 7之前，我可以记得的最久远的，VxWorks的启动过程都是一样的：所谓的VxWorks ‘bootrom'是存在于flash存储当中并从复位开始自动运行。bootrom会初始化所有运行VxWorks所需的硬件，然后加载VxWorks系统（通常以ELF文件形式存在）到内存并运行它，bootrom可以从包括可用格式的flash存储文件系统加载VxWorks镜像，或者通过网络连接从另一台机器上加载。
诚然，bootrom是内置了一个应用程序的VxWorks的特殊的编译镜像，此应用程序只是用来加载主要的VxWorks系统镜像。这个特殊的编译镜像包含了能将处理器从复位状态启动的代码，并能将系统启动到一个工作的状态；通常这包含设置时钟，管脚复用，内存控制器等等。bootrom的另一个特殊功能是它是可以驻留并安装在只读存储上的。
尽管这个方法在过去一直工作得很好，但它还是有一些问题：
- 如果你为一个客制化的硬件来设计一个BSP，你会遇到”鸡和蛋“的问题：在你拥有一个可工作的bootrom前你需要一个可正常工作的BSP，而在你可以测试并调试一个BSP前你（常常）需要一个可以正常工作的bootrom。
- 因为片上系统（SoCs）集成了更多的功能，初始化硬件的过程变得更加的复杂，在某些时候芯片厂家并没有非常好地用文档记录。
- 片上系统（SoCs）已经开始包含他们自己的内置启动代码用来支持从不同的存储启动，包括NOR flash，SD卡等等。这使得基于一个VxWorks BSP来编译一个可以和片上系统的启动代码在各种可能的情形下一起工作变得更加困难。
VxWorks 7带来了哪些变化
尽管启动VxWorks 7的整体过程和老版本很相似，但是一些细节还是有非常大的变化，主要的变化如下：
微信公众号
© 2024 VxWorks Club