Thanks for sending an requirement! Please fill in the following template to help quickly solve your problem.

Backgroud（背景信息）

Runtime 当前 chipType 获取存在两套来源：Runtime 初始化阶段通过 halGetSocVersion 获取 socVersion 后依赖各平台 dev_info_reg.cc 注册的 DEV_INFO 全局表反查 chipType；rtSetSocVersion 阶段依赖 SOC_INFO 全局表反查 chipType。同时 Runtime 已具备基于 ini 的平台配置读取能力，但 socVersion -> chipType 映射仍散落在各平台静态数组中，新增或调整产品形态时需要同步修改代码和配置，维护成本较高。

本需求要求将 socVersion -> chipType 的数据源统一收敛到平台 ini 配置中的 [version].Chip_type 字段，并清理 Runtime 中不再需要的 DEV_INFO/SOC_INFO 注册表逻辑。对于 910C 之前芯片，继续保留 hardwareVersion -> chipType/socVersion 的 legacy fallback 能力；对于 910C 及之后芯片，统一依赖 halGetSocVersion 返回的 socVersion 和平台 ini 中的 Chip_type。

Origin（信息来源）

设计团队提出的需求

Benefit / Necessity （价值/作用）

该需求可以将 rtSetSocVersion 与 Runtime 初始化路径的 chipType 来源统一为平台配置，避免同一映射在代码注册表和 ini 配置中重复维护。新增或调整 SoC 形态时，Runtime 侧无需继续扩展 BATCH_REGISTER_SOC_INFO/BATCH_REGISTER_DEV_INFO 静态数组，有助于降低平台适配成本，并减少配置与代码映射不一致带来的运行时风险。

清理 DevInfoManage 中 socInfo/devInfo 注册、存储和查询逻辑后，各平台 dev_info_reg.cc 文件只保留平台 so、feature、properties 等仍有效的注册职责，模块边界更清晰。通过补齐当前仓 ini 的 Chip_type 字段、适配跨仓 SoC 的 UT stub，并增加缺失、非数字、越界、查询失败等负向用例，可以提升新链路的可验证性和异常处理一致性。

Design（设计方案）

总体设计为：以平台 ini 的 [version].Chip_type 作为 socVersion -> chipType 的唯一来源，公共读取逻辑集中在 soc_info.h/.cc，Runtime 初始化和 rtSetSocVersion 共同复用该接口。

1. 新增统一平台读取接口：

   • 在 src/runtime/core/src/common/soc_info.h/.cc 新增 GetChipTypeFromPlatform。
   • 通过 PlatformManagerV2::Instance().GetSocSpec(socName, "version", "Chip_type", value) 读取 ini 配置。
   • 将读取值按十进制解析为 rtChipType_t。
   • 对空指针、字段缺失、非数字、解析残留、越界 [CHIP_BEGIN, CHIP_END) 等场景返回 RT_ERROR_INVALID_VALUE。

2. 改造 rtSetSocVersion：

   • 用 GetChipTypeFromPlatform(ver, chipType) 替换旧的 GetSocInfoFromRuntimeByName(ver, socInfo)。
   • 保留入参判空和 hardwareSocVersion 一致性校验。
   • 成功后继续设置 GlobalContainer::SetRtChipType(chipType)、SetUserSocVersion(ver)、SetSocVersion(ver)，并调用 Runtime::UpdateDevProperties(chipType, ver)。
   • 查询失败时统一返回非法参数错误。

3. 改造 Runtime 初始化链路：

   • Runtime::InitSocVersionAndChipType 优先调用 halGetSocVersion。
   • 当 halGetSocVersion 成功且返回非空 socVersion 时，直接通过 GetChipTypeFromPlatform(socVersion, chipType_) 读取 chipType_，不再访问 DevInfoManage::GetDevInfo。
   • 当 halGetSocVersion 不支持或返回空时，继续走 halGetDeviceInfo(... INFO_TYPE_VERSION ...) legacy fallback，通过 hardwareVersion 得到 chipType_，再由 GetSocVersionByHardwareVer 补齐 socVersion_。
   • GetSocVersionByHardwareVer 仅保留 910C 之前芯片分支，删除 CHIP_910_B_93、CHIP_MC62CM12A、CHIP_MC32DM11A 以及废弃 CHIP_MINI -> Ascend310 等不再由 fallback 推断的路径。

4. 清理旧注册表：

   • 删除 DevInfoManage 中 RegisterSocInfo、BatchRegSocInfo、GetSocInfo、RegisterDevInfo、BatchRegDevInfo、GetDevInfo。
   • 删除对应的 socInfos/devInfos 容器、读写锁及 REGISTER_SOC_INFO、BATCH_REGISTER_SOC_INFO、REGISTER_DEV_INFO、BATCH_REGISTER_DEV_INFO 宏。
   • 清理各平台 src/runtime/config/*/dev_info_reg.cc 中的 rtSocInfo_t 全局数组及批量注册代码，保留平台 so、feature、properties、proc func 等注册逻辑。

5. 补齐平台配置：

   • 在当前仓 src/platform/platform_config/**/*.ini 的 [version] 段补齐 Chip_type 字段。
   • Chip_type 使用 Runtime rtChipType_t 的十进制枚举值，例如 Ascend910A 为 1、Ascend910B1 为 5、Ascend950PR_9599 为 15、Kirin9030 为 20。
   • 对当前仓不存在 ini、但仍需支持的跨仓 SoC，单仓 UT 通过 PlatformManagerV2::GetSocSpec stub 模拟；真实安装形态需由聚合后的 data/platform_config 提供对应 ini。

6. 测试适配：

   • 将 dev_info_manage_test 中旧 GetSocInfo/GetDevInfo 用例迁移为 GetChipTypeFromPlatform 正向和负向用例。
   • 在 platform_stub.cc 增加表驱动 SoC 配置，覆盖 Ascend910A、Ascend910B1、BS9SX1AA、Ascend610Lite、AS31XM1X、MC62CM12AA、MC32DM11AA、Ascend950PR_9599 等场景。
   • 为 Chip_type 缺失、非数字、越界、查询错误等场景增加稳定错误注入。
   • 更新 rtSetSocVersion、InitSocVersionAndChipType、GetSocVersionByHardwareVer 相关用例，验证新平台配置链路和 legacy fallback 边界。