从 Coreboot 中删除旧 AMD CPU 和主板支持,代码减少约 738k 行
Upstream Coreboot 已逐步停止支持较旧的 AMD 14h / 15h / 16h 系列处理器和相关主板。
如 Phoronix 所述,由于这些较旧的 AMD 平台依赖于旧的 SMP 初始化路径,并且从未移植到较新的代码,因此在弃用之后,这些 targets 已从上游 Coreboot 中删除。事实上,考虑到这些较旧的 ports 未进行维护且未针对任何新的 Coreboot 功能等进行调整,此举乃是意料之中。那些仍在运行带有 Coreboot 固件的旧 AMD 主板的用户可以继续使用其现有固件。同样,由于 Git 和现有的 Coreboot tagged releases;如果需要的话,那些选择这些旧 AMD 主板的人可以继续运行以前的 Coreboot 版本。但就上游而言,这些旧的 AMD CPU/主板不再受支持。
此前,AMD 也有过为新平台积极贡献上游的时候。他们曾积极为新的 APU 平台积极支持 Coreboot —— 在2011 年承诺在未来的 CPU 中支持 Coreboot,但也只持续了几年。逐渐的,他们对 Coreboot 的贡献往往就仅限于在 Google Chromebook 中使用的硬件。现在,他们在十年前与工程合作伙伴一起积极推动Coreboot 支持时所编写的所有代码则都已从主线中删除。
清除旧的 LEGACY_SMP_INIT 代码、旧 motherboards 和旧 AMD 平台代码使 Coreboot 代码减少了约 738k 行。
AMD Family 15h Bulldozer era 的支持被取消,其中包括:
- “Parmer”和“Thatcher”的 Reference boards
- ASUS A88XM-E
- ASUS F2A85-M
- HP Pavilion M6 1035DX
- Lenovo G505S
- MSI MS-7721 FM2-A55M-E3
AMD Family 14h “Bobcat” CPU 也被砍掉了,包括以下 boards:
- AMD Iguana,South Station 、Union Station 和 Persimmon reference boards
- ASRock E350M1
- Elmex PCM205400
- Elmex PCM205401
- Gizmosphere Gizmo
- Jetway NF81-T56N-LF
- Lippert Frontrunner-AF
- PC Engines APU1
AMD Family 16h boards 也从 Coreboot 中剥离,这影响了以下 boards :
- AMD Olivehill reference board
- ASRock IMB-A180
- ASUS AM1I-A
- BAP ODE_E20XX
- Biostar A68N-5200
- Biostar AM1ML
- Gizmosphere Gizmo2
- HP ABM

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Grafana Labs 最新开源项目:持续分析数据库 Phlare 和前端可观测性库 Faro
Grafana Labs 近日开源了两个新项目,分别是用于大规模持续性能分析 (Continuous Profiling) 的开源数据库Phlare,以及用于前端应用可观测性的 Faro。 Grafana Phlare Grafana Phlare 是一个用于聚合持续分析 (Continuous Profiling) 数据的开源项目,它可以和 Grafana 完全集成,允许你与其他可观察信号相关联。 Grafana Labs 介绍道,Profiling 可用于分析程序的资源使用情况,进而帮助开发者优化程序的性能和成本。但当下主流的分布式云原生架构让 Profiling 这件事变得更加复杂,从而产生了对持续分析 (Continuous Profiling) 的需求,其中有关资源使用情况的信息会在整个计算基础设施中定期自动收集,然后压缩并存储为时间序列数据,这使开发者能够可视化查看随时间的变化并放大与感兴趣的时间段相匹配的 profile 文件 —— 例如,CPU 在其利用率最高时所花费的时间,或函数调用的频率和持续时间。 Grafana Labs 称"Continuous Profili...
- 下一篇
京东云开发者|代码评审的价值和规范
评审目的 代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代,始终保持一个较高的水平,所有在评审中使用的工具和流程都应是为此目的而设计的。 评审原则 鼓励质疑 保持代码风格,遵守开发规范 优先设计原则,尊重个人偏好 重视每一行代码 尽可能采用面对面的形式 评审时机 研发流程应该是严密的、有节奏的,而个体的代码质量会影响整体交付进度,所以请第一时间启动代码评审,最晚不要超过早期测试阶段。 如果是异步评审的机制,评审过程最好不要超过一个工作日,如果评审时间较长,请在开始评审时进行初步反馈。 评审范围 1. 功能 这个Change List是否达到了预期目标? 并发、数据权限、性能、竞态条件等一系列边缘异常是否合理规避? 2. 复杂性 新增的复杂是否是值得的? 复杂设计的实现是否是可读的? 抽象定义是否是优雅整洁的? 鼓励通过设计提高可扩展性,但不可“面向未来做设计”,二者之间的界限应该是:是否能够看到明确的演进方向(actual shape)和需求 3. 单元测试 是否有单元测试? 单元测试是否具有良好的可读性? 每一个测试是否有断言? 是否能覆盖尽可能多的逻辑分支? 4. 命名...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- Linux系统CentOS6、CentOS7手动修改IP地址
- 2048小游戏-低调大师作品
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案