CN106598602A

CN106598602A - 一种支持多操作系统加载的方法及加载器

Info

Publication number: CN106598602A
Application number: CN201611166728.7A
Authority: CN
Inventors: 张尧学; 郭慧; 任炬; 刘亚萍; 陈娅芳; 李政军
Original assignee: Hunan Information Technology Co Ltd; Central South University
Current assignee: HUNAN NEW CLOUDNET TECHNOLOGY CO., LTD.
Priority date: 2016-12-16
Filing date: 2016-12-16
Publication date: 2017-04-26

Abstract

本发明公开了一种支持多操作系统加载的方法及加载器，方法包括：S1. 加载器获取底层硬件设备的API接口；S2. 加载器在所述API接口的上层将所述API接口标准化为对应不同操作系统的操作系统API接口；S3. 加载器将所述操作系统API接口提供给操作系统层，供操作系统直接调用。加载器包括底层接口获取层，中层接口转换层和顶层接口暴露层。本发明不需要通过刷机，即可以实现对多种操作系统支持，可方便的实现不同类型操作系统在智能终端的部署，具有部署效率高，使用方便等优点。

Description

一种支持多操作系统加载的方法及加载器

技术领域

本发明涉及智能终端系统加载技术领域，尤其涉及一种支持多操作系统加载的方法及加载器。

背景技术

随着物联网技术的飞速发展，智能终端设备的种类越来越多，终端设备需求的功能也越来越丰富，目前适用于智能终端上的操作系统的种类和版本多种多样，例如FreeRTOS、uCOS、TinyOS等等。这些具有实时操作系统的智能终端设备，无论是可穿戴设备，还是物联网中的终端，其功能都是更加出色的，其扩展性更是那些无操作系统的终端所无法比拟的。

但是，在各种智能终端操作系统的发展过程中，由于不同操作系统之间的差异，使得它们的使用侧重点也越来越明显。而智能终端设备往往只能固定的加载一种操作系统，如果需要更换操作系统，只能通过刷机实现，无法根据用户的需求随时选择不同的操作系统。并且，由于智能终端设备的加载器只能提供一种操作系统的API接口，因此，即使通过刷机可以刷写不同的操作系统，但这些不同的操作系统只能是同一操作系统的不同版本，无法真正做到对任意操作系统的支持。

发明内容

本发明要解决的技术问题就在于：针对现有技术存在的技术问题，本发明提供一种不需要通过刷机，即可以实现对多种操作系统支持，可方便的实现不同类型操作系统在智能终端的部署，部署效率高，使用方便的支持多操作系统加载的方法及加载器。

为解决上述技术问题，本发明提出的技术方案为：一种支持多操作系统加载的方法，包括：

S1. 加载器获取底层硬件设备的API接口；

S2. 加载器在所述API接口的上层将所述API接口标准化为对应不同操作系统的操作系统API接口；

S3. 加载器将所述操作系统API接口提供给操作系统层，供操作系统直接调用。

作为本发明的进一步改进，在所述步骤S1中，还包括所述加载器对底层硬件设备的初始化。

作为本发明的进一步改进，所述底层硬件设备的API接口包括无线网络接口和透明计算协议接口。

一种支持多操作系统加载的加载器,包括底层接口获取层，中层接口转换层和顶层接口暴露层；所述底层接口获取层用于获取底层硬件设备的API接口，所述中层接口转换层用于将所述底层硬件设备的API接口标准化为对应不同操作系统的操作系统API接口，所述顶层接口暴露层用于将所述操作系统API接口提供给具体的操作系统直接调用。

作为本发明的进一步改进，所述底层接口获取层还用于对底层硬件设备的API接口进行初始化。

与现有技术相比，本发明的优点在于：本发明不需要通过刷机，即可以实现对多种操作系统支持，可方便的实现不同类型操作系统在智能终端的部署，具有部署效率高，使用方便等优点。

附图说明

图1为本发明具体实施例流程示意图。

图2为本发明具体实施例结构示意图。

具体实施方式

以下结合说明书附图和具体优选的实施例对本发明作进一步描述，但并不因此而限制本发明的保护范围。

如图1所示，本实施例的支持多操作系统加载的方法，包括：S1. 加载器获取底层硬件设备的API接口；S2. 加载器在API接口的上层将API接口标准化为对应不同操作系统的操作系统API接口；S3. 加载器将操作系统API接口提供给操作系统层，供操作系统直接调用。

在本实施例的步骤S1中，还包括加载器对底层硬件设备的初始化。底层硬件设备的API接口包括无线网络接口和透明计算协议接口。

在本实施例中，以内置Flash接口为例进行具体说明。位于底层的Flash设备需要通过底层的Flash读写驱动程序来实现对Flash设备的读写操作，同时Flash读写驱动将其API接口提供给上层操作系统，供上层操作系统进行调用。

在本实施例中，Flash读写驱动文件Flash.c中的读写函数如下所示：

void CMD_READ( uint32 flash_address, uint8 *target_address, uint32 byte_length )

{

while(IsFlashBusy());

SPI_CS_LOW;

SendByte(FLASH_CMD_READ);

SendFlashAddr(flash_address);

#if USE_SPI_BYTE

for(uint32 i=0; i<byte_length; i++)

{

*(target_address+i) = GetByte();

}

#else

spi_get_buff(target_address, byte_length);

#endif

SPI_CS_HIGH;

}

读写函数CMD_READ( )需要提供API给操作系统调用。而在在现有技术中，只有该Flash读写驱动直接支持的操作系统OS可直接调用该读写函数CMD_READ( )的API接口，而对于其他不同类型的操作系统，由于对底层Flash读写驱动的API接口并不相同，操作系统OS1进行Flash读操作需要调用的API接口为OS1_Flash_Read，而操作系统OS2进行Flash读操作需要调用的API接口为OS2_Flash_Read，操作系统OS3进行Flash读操作需要调用的API接口为OS3_Flash_Read，因此，智能终端无法实现对不同操作系统的支持。如果智能终端需要加载OS1、或OS2、或OS3，需要连接底层的Flash读写驱动一并刷写，从而才能使得新刷写的操作系统可以正常运行。

在本实施例中，通过加载器获取Flash读写驱动的API接口，并将该Flash读写驱动的API接口进行转换，针对不同类型的操作系统OS1、OS2、OS3，将Flash的读写函数进行转换，转换为与操作系统对应的不同标准化的操作系统API接口，分别OS1_Flash_Read、OS2_Flash_Read和OS3_Flash_Read。在Config.c文件中进行转换，转换形式如下所示：

#define OS1_Flash_Read( uint32 flash_address, uint8 *target_address,uint32 byte_length ) \

CMD_READ( uint32 flash_address, uint8 *target_address, uint32 byte_length)

#define OS2_Flash_Read( uint32 flash_address, uint8 *target_address,uint32 byte_length ) \

CMD_READ( uint32 flash_address, uint8 *target_address, uint32 byte_length)

#define OS3_Flash_Read( uint32 flash_address, uint8 *target_address,uint32 byte_length ) \

CMD_READ( uint32 flash_address, uint8 *target_address, uint32 byte_length)

通过上述转换过程，加载器同时具有三种不同的Flash读写驱动的API接口，OS1_Flash_Read、OS2_Flash_Read和OS3_Flash_Read。通过将这三个API接口暴露给上层的操作系统，即可实现不同的上层操作系统对Flash读写驱动的API接口的直接调用。在本实施例中，通过Bootloader_symbol.c文件创建OS_LIBS_EXPORT（）函数实现API的暴露，形式如下：

OS_LIBS_EXPORT(“OS1_Flash_Read”, OS1_Flash_Read)

OS_LIBS_EXPORT(“OS2_Flash_Read”, OS2_Flash_Read)

OS_LIBS_EXPORT(“OS3_Flash_Read”, OS3_Flash_Read)

其中，OS_LIBS_EXPORT的定义如下：

#define OS_LIBC_EXPORT(name,symbol)

const char __ossym_##symbol##_name[] = name;

const struct os_module_symtab __ossym_##symbol __attribute__ ((section("OSSymbolTable")))= \

{ \

(void *)&symbol, \

__ossym_##symbol##_name \

};

在本实施例中，通过加载器将底层硬件设备驱动的API接口转换为与具体操作系统相对应的标准化的API接口，可实现在智能终端加载不同的操作系统时，操作系统可以直接调用加载器所提供的与该操作系统相适应的标准化API接口，无需要关注底层硬件API接口是否与操作系统一致。通过加载器直接加载操作系统到智能终端即可运行，从而使得智能终端的操作系统加载、部署变得十分的灵活、方便，提高了智能终端的操作系统部署效率。

如图2所示，本实施例的支持多操作系统加载的加载器，包括底层接口获取层，中层接口转换层和顶层接口暴露层；底层接口获取层用于获取底层硬件设备的API接口，中层接口转换层用于将底层硬件设备的API接口标准化为对应不同操作系统的操作系统API接口，顶层接口暴露层用于将操作系统API接口提供给具体的操作系统直接调用。底层接口获取层还用于对底层硬件设备的API接口进行初始化。底层硬件设备的API接口包括无线网络接口和透明计算协议接口。

上述只是本发明的较佳实施例，并非对本发明作任何形式上的限制。虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明。因此，凡是未脱离本发明技术方案的内容，依据本发明技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均应落在本发明技术方案保护的范围内。

Claims

1.一种支持多操作系统加载的方法，其特征在于：

S1. 加载器获取底层硬件设备的API接口；

2.根据权利要求1所述的支持多操作系统加载的方法，其特征在于：在所述步骤S1中，还包括所述加载器对底层硬件设备的初始化。

3.根据权利要求2所述的支持多操作系统加载的方法，其特征在于：所述底层硬件设备的API接口包括无线网络接口和透明计算协议接口。

4.一种支持多操作系统加载的加载器，其特征在于：包括底层接口获取层，中层接口转换层和顶层接口暴露层；所述底层接口获取层用于获取底层硬件设备的API接口，所述中层接口转换层用于将所述底层硬件设备的API接口标准化为对应不同操作系统的操作系统API接口，所述顶层接口暴露层用于将所述操作系统API接口提供给具体的操作系统直接调用。

5.根据权利要求4所述的支持多操作系统加载的加载器，其特征在于：所述底层接口获取层还用于对底层硬件设备的API接口进行初始化。

6.根据权利要求5所述的支持多操作系统加载的加载器，其特征在于：所述底层硬件设备的API接口包括无线网络接口和透明计算协议接口。