内核

内核

龙芯下 IRQ7 干啥用的?

lemote1 回复了问题 • 2 人关注 • 1 个回复 • 84 次浏览 • 2018-02-10 16:40 • 来自相关话题

最强龙芯+最新内核+最大内存

lemote1 发表了文章 • 34 个评论 • 328 次浏览 • 2018-01-30 22:07 • 来自相关话题

 

Screensho.png

 

loongnix 能否出个高版本内核 src.rpm ?

heiher 回复了问题 • 3 人关注 • 2 个回复 • 168 次浏览 • 2018-01-05 21:44 • 来自相关话题

关于 Meltdown 与 Spectre 对龙芯影响的初步看法

xen0n 发表了文章 • 7 个评论 • 1210 次浏览 • 2018-01-05 18:08 • 来自相关话题

今天休息时候花了点时间思考龙芯平台有没有这两个漏洞。本来不想说话,但看到一个 RISC-V 阵营趁乱发的 PR 稿(https://riscv.org/2018/01/more ... -isa/ ),气死了,就来写点东西。原贴在贴吧发的,果然被秒删了,可能因为带了一些链接的缘故吧。那就来这边发了,正好小白也少。

关于 Meltdown,讲道理,龙芯实际上完全有可能受影响。因为 Linux 页表在 4.15-rc6 之前的的确确只有 1 份,而龙芯上并没有人做实验确认龙芯 MMU 面对攻击场景的行为模式。正常而言,即便单纯出于直觉判断,由于 TLB 的存在,mapped pages 肯定后续访问要快一些,这就很爆炸了;只是还需要在龙芯上找到类似 Intel TSX-NI 的降低操作系统 exception handler 运行时间噪声的机制。如果这种机制确实存在,那龙芯其实跟 Intel 一样爆炸。只是关心的人暂时没那么多罢了。(当然该关心的都在关心,这个没跑了。)

至于 Spectre,看了下 gist.github.com 有一份源码;用到了 rdtscp 跟 clflush 两个指令,试图从 victim_function 里间接读取它访问的内存。龙芯上 rdtsc(p) 是有等价物的,它貌似叫 rdhwr $31 还是 $29 来着,忘记了;clflush 从用户态刷缓存的,我找了一圈,貌似没看到,只有 Linux/MIPS wiki 上有讲到用系统调用让内核代劳,不清楚语义。有兴趣的小伙伴可以仔细研究一下 MIPS 指令集跟龙芯的用户手册。

总之就是希望大家可以讨论一下,最好能试着在龙芯上编译运行这两个漏洞的 PoC;能复现的话,就是对龙芯现阶段最好的事情之一了。 查看全部
今天休息时候花了点时间思考龙芯平台有没有这两个漏洞。本来不想说话,但看到一个 RISC-V 阵营趁乱发的 PR 稿(https://riscv.org/2018/01/more ... -isa/ ),气死了,就来写点东西。原贴在贴吧发的,果然被秒删了,可能因为带了一些链接的缘故吧。那就来这边发了,正好小白也少。

关于 Meltdown,讲道理,龙芯实际上完全有可能受影响。因为 Linux 页表在 4.15-rc6 之前的的确确只有 1 份,而龙芯上并没有人做实验确认龙芯 MMU 面对攻击场景的行为模式。正常而言,即便单纯出于直觉判断,由于 TLB 的存在,mapped pages 肯定后续访问要快一些,这就很爆炸了;只是还需要在龙芯上找到类似 Intel TSX-NI 的降低操作系统 exception handler 运行时间噪声的机制。如果这种机制确实存在,那龙芯其实跟 Intel 一样爆炸。只是关心的人暂时没那么多罢了。(当然该关心的都在关心,这个没跑了。)

至于 Spectre,看了下 gist.github.com 有一份源码;用到了 rdtscp 跟 clflush 两个指令,试图从 victim_function 里间接读取它访问的内存。龙芯上 rdtsc(p) 是有等价物的,它貌似叫 rdhwr $31 还是 $29 来着,忘记了;clflush 从用户态刷缓存的,我找了一圈,貌似没看到,只有 Linux/MIPS wiki 上有讲到用系统调用让内核代劳,不清楚语义。有兴趣的小伙伴可以仔细研究一下 MIPS 指令集跟龙芯的用户手册。

总之就是希望大家可以讨论一下,最好能试着在龙芯上编译运行这两个漏洞的 PoC;能复现的话,就是对龙芯现阶段最好的事情之一了。

编译内核 4.4.30 的 src.rpm 出现这个错误

iapcmloongson 回复了问题 • 2 人关注 • 1 个回复 • 146 次浏览 • 2017-12-21 08:52 • 来自相关话题

按照官方文档编译内核失败

admin 回复了问题 • 4 人关注 • 5 个回复 • 525 次浏览 • 2017-12-13 15:21 • 来自相关话题

由 expat 编译错误揭示的 Loongnix 巨坑,以及由此生发的关于社区互动的思考

xen0n 发表了文章 • 96 个评论 • 1168 次浏览 • 2017-11-11 19:28 • 来自相关话题

本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h 2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然!
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。
 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。 查看全部
本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:
--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h       2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
  1. 反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;
  2. 维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。
  3. upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。

 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。

龙芯支持CPU0的逻辑下线吗?

lemote1 回复了问题 • 2 人关注 • 1 个回复 • 163 次浏览 • 2017-10-20 16:07 • 来自相关话题

龙芯3A1000开发板上如何接串口?

xueyan 回复了问题 • 3 人关注 • 4 个回复 • 206 次浏览 • 2017-10-20 14:38 • 来自相关话题

R7 350的显卡,3.10的内核支持,4.4怎么不行了

lemote1 回复了问题 • 4 人关注 • 3 个回复 • 311 次浏览 • 2017-10-02 15:05 • 来自相关话题

条新动态, 点击查看
请参考:《Loongson_Kernel编译与使用》 http://www.loongnix.org/index.php/Loongson_Kernel%E7%BC%96%E8%AF%91%E4%B8%8E%E4%BD%BF%E7%94%A8
  显示全部 »
请参考:《Loongson_Kernel编译与使用》 http://www.loongnix.org/index.php/Loongson_Kernel%E7%BC%96%E8%AF%91%E4%B8%8E%E4%BD%BF%E7%94%A8
 
lixuefeng

lixuefeng 回答了问题 • 2017-02-10 16:48 • 1 个回复 不感兴趣

MSI-X的支持

赞同来自:

目前龙芯平台对应的内核,在官方对外发布的版本上还没有稳定的对msi中断的支持。
某些定制版本有支持,但是还没有合并到对外发布的代码树上。
目前龙芯平台对应的内核,在官方对外发布的版本上还没有稳定的对msi中断的支持。
某些定制版本有支持,但是还没有合并到对外发布的代码树上。
DaDou13

DaDou13 回答了问题 • 2017-02-17 23:02 • 3 个回复 不感兴趣

在Loongnix上编译内核,安装不成功

赞同来自:

说一下我的安装过程
安装模块
sudo make modules_install
生成initrd文件
sudo mkinitrd /boot/initramfs.3.10.84.img 3.10.84    #后面的“3.10.84”是在/lib/modul... 显示全部 »
说一下我的安装过程
安装模块
sudo make modules_install
生成initrd文件
sudo mkinitrd /boot/initramfs.3.10.84.img 3.10.84    #后面的“3.10.84”是在/lib/modules目录下相应的目录名,注意空格
复制内核文件
sudo cp vmlinux /boot/vmlinuz.3.10.84    #注意空格
最后修改/boot/boot.cfg文件。参照已有内核的启动信息,编写自己编译的内核的启动信息。不要把原来内核的启动信息删了,万一编译的启动不了,可以用老内核启动。
内核和initrd文件的文件名可以改成方便自己辨别的。
 

Fedora21上如何启动自己编译的内核?

回复

loongnix 回复了问题 • 1 人关注 • 1 个回复 • 278 次浏览 • 2017-03-13 11:26 • 来自相关话题

龙芯下 IRQ7 干啥用的?

回复

lemote1 回复了问题 • 2 人关注 • 1 个回复 • 84 次浏览 • 2018-02-10 16:40 • 来自相关话题

loongnix 能否出个高版本内核 src.rpm ?

回复

heiher 回复了问题 • 3 人关注 • 2 个回复 • 168 次浏览 • 2018-01-05 21:44 • 来自相关话题

编译内核 4.4.30 的 src.rpm 出现这个错误

回复

iapcmloongson 回复了问题 • 2 人关注 • 1 个回复 • 146 次浏览 • 2017-12-21 08:52 • 来自相关话题

按照官方文档编译内核失败

回复

admin 回复了问题 • 4 人关注 • 5 个回复 • 525 次浏览 • 2017-12-13 15:21 • 来自相关话题

龙芯支持CPU0的逻辑下线吗?

回复

lemote1 回复了问题 • 2 人关注 • 1 个回复 • 163 次浏览 • 2017-10-20 16:07 • 来自相关话题

龙芯3A1000开发板上如何接串口?

回复

xueyan 回复了问题 • 3 人关注 • 4 个回复 • 206 次浏览 • 2017-10-20 14:38 • 来自相关话题

R7 350的显卡,3.10的内核支持,4.4怎么不行了

回复

lemote1 回复了问题 • 4 人关注 • 3 个回复 • 311 次浏览 • 2017-10-02 15:05 • 来自相关话题

求一个能用的 4.12 的内核配置文件。

回复

DaDou13 回复了问题 • 2 人关注 • 1 个回复 • 169 次浏览 • 2017-09-07 23:13 • 来自相关话题

请问,龙芯1号系列 是否有计划对Zephyr 的 支持呢?

回复

qq910438219 发起了问题 • 1 人关注 • 0 个回复 • 176 次浏览 • 2017-07-22 23:18 • 来自相关话题

mips .insn指令含义

回复

Eric 发起了问题 • 1 人关注 • 0 个回复 • 166 次浏览 • 2017-06-20 11:01 • 来自相关话题

最强龙芯+最新内核+最大内存

lemote1 发表了文章 • 34 个评论 • 328 次浏览 • 2018-01-30 22:07 • 来自相关话题

 

Screensho.png

 

关于 Meltdown 与 Spectre 对龙芯影响的初步看法

xen0n 发表了文章 • 7 个评论 • 1210 次浏览 • 2018-01-05 18:08 • 来自相关话题

今天休息时候花了点时间思考龙芯平台有没有这两个漏洞。本来不想说话,但看到一个 RISC-V 阵营趁乱发的 PR 稿(https://riscv.org/2018/01/more ... -isa/ ),气死了,就来写点东西。原贴在贴吧发的,果然被秒删了,可能因为带了一些链接的缘故吧。那就来这边发了,正好小白也少。

关于 Meltdown,讲道理,龙芯实际上完全有可能受影响。因为 Linux 页表在 4.15-rc6 之前的的确确只有 1 份,而龙芯上并没有人做实验确认龙芯 MMU 面对攻击场景的行为模式。正常而言,即便单纯出于直觉判断,由于 TLB 的存在,mapped pages 肯定后续访问要快一些,这就很爆炸了;只是还需要在龙芯上找到类似 Intel TSX-NI 的降低操作系统 exception handler 运行时间噪声的机制。如果这种机制确实存在,那龙芯其实跟 Intel 一样爆炸。只是关心的人暂时没那么多罢了。(当然该关心的都在关心,这个没跑了。)

至于 Spectre,看了下 gist.github.com 有一份源码;用到了 rdtscp 跟 clflush 两个指令,试图从 victim_function 里间接读取它访问的内存。龙芯上 rdtsc(p) 是有等价物的,它貌似叫 rdhwr $31 还是 $29 来着,忘记了;clflush 从用户态刷缓存的,我找了一圈,貌似没看到,只有 Linux/MIPS wiki 上有讲到用系统调用让内核代劳,不清楚语义。有兴趣的小伙伴可以仔细研究一下 MIPS 指令集跟龙芯的用户手册。

总之就是希望大家可以讨论一下,最好能试着在龙芯上编译运行这两个漏洞的 PoC;能复现的话,就是对龙芯现阶段最好的事情之一了。 查看全部
今天休息时候花了点时间思考龙芯平台有没有这两个漏洞。本来不想说话,但看到一个 RISC-V 阵营趁乱发的 PR 稿(https://riscv.org/2018/01/more ... -isa/ ),气死了,就来写点东西。原贴在贴吧发的,果然被秒删了,可能因为带了一些链接的缘故吧。那就来这边发了,正好小白也少。

关于 Meltdown,讲道理,龙芯实际上完全有可能受影响。因为 Linux 页表在 4.15-rc6 之前的的确确只有 1 份,而龙芯上并没有人做实验确认龙芯 MMU 面对攻击场景的行为模式。正常而言,即便单纯出于直觉判断,由于 TLB 的存在,mapped pages 肯定后续访问要快一些,这就很爆炸了;只是还需要在龙芯上找到类似 Intel TSX-NI 的降低操作系统 exception handler 运行时间噪声的机制。如果这种机制确实存在,那龙芯其实跟 Intel 一样爆炸。只是关心的人暂时没那么多罢了。(当然该关心的都在关心,这个没跑了。)

至于 Spectre,看了下 gist.github.com 有一份源码;用到了 rdtscp 跟 clflush 两个指令,试图从 victim_function 里间接读取它访问的内存。龙芯上 rdtsc(p) 是有等价物的,它貌似叫 rdhwr $31 还是 $29 来着,忘记了;clflush 从用户态刷缓存的,我找了一圈,貌似没看到,只有 Linux/MIPS wiki 上有讲到用系统调用让内核代劳,不清楚语义。有兴趣的小伙伴可以仔细研究一下 MIPS 指令集跟龙芯的用户手册。

总之就是希望大家可以讨论一下,最好能试着在龙芯上编译运行这两个漏洞的 PoC;能复现的话,就是对龙芯现阶段最好的事情之一了。

由 expat 编译错误揭示的 Loongnix 巨坑,以及由此生发的关于社区互动的思考

xen0n 发表了文章 • 96 个评论 • 1168 次浏览 • 2017-11-11 19:28 • 来自相关话题

本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h 2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然!
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。
 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。 查看全部
本人在前一阵子团购的 3A3000 开发板上安装了 Gentoo 系统。但由于一直没有时间移植个人所用的 Linux 补丁,一直用 Loongnix 的 linux-3.10.84 临时顶上内核的位置。一开始用 amd64 机器交叉编译的方式自举了整个基本系统,为了简单起见,没有打开 multilib 支持;在 3A3000 上成功引导之后,再打开了 multilib,安装其他软件,整个过程还算顺利。
 
然而在 10 月份后续更新系统的过程中,马上发现 expat 库永远编译不过,安装过程报 expat_config.h header checksum mismatch,意思是这个文件在不同的 multilib ABI 下内容不一致。但有意思的是,无论是 expat 上游还是 Gentoo 社区都完全找不到这个 bug!当时因为工作比较忙,于是没有深究了。
 
最近虽然工作愈发地忙起来了,但正好想搭建一个 Linux 的本地测试环境,公司的后端又用的 Golang,所以想着放在脚旁边的龙芯很适合。于是 expat 这个库挡住了很多软件的编译,我又不想 pin 住它的版本,所以开始继续研究了。
 
两个文件的差异是这样的:
--- ./expat-2.2.5-abi_mips_o32.o32/expat_config.h       2017-11-10 16:07:07.241011603 +0800
+++ ./expat-2.2.5-abi_mips_n64.n64/expat_config.h 2017-11-10 16:07:40.819296062 +0800
@@ -23,7 +23,7 @@
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getrandom' function. */
-/* #undef HAVE_GETRANDOM */
+#define HAVE_GETRANDOM 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1
@@ -53,7 +53,7 @@
#define HAVE_STRING_H 1

/* Define to 1 if you have `syscall' and `SYS_getrandom'. */
-#define HAVE_SYSCALL_GETRANDOM 1
+/* #undef HAVE_SYSCALL_GETRANDOM */

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1





这是什么情况? o32 ABI 下没有 getrandom 函数,但 n64 下却有?(看了 configure.ac 文件,上边的判断为假才会检测下边那个不一致对应的选项,所以相当于只有一处不一致。)连单个架构下 ABI 都不能保持一致的 syscall 实现,这种代码怎么可能逃过 Linux 各大子系统 maintainers 的法眼,而进入主线内核呢?
 
等下,我们用的是 Loongnix 的内核,好像还是 3.10.84 版本,这个版本根本就不该有 getrandom,龙芯团队的内核补丁水平我们也是知道的……果然
 
按照一般的商业逻辑还原一下场景,应该是龙芯的某个客户一定要使用 getrandom 系统调用,龙芯团队就给他加上了;但按照 Loongnix 代码库提交历史,能感受到龙芯的研发团队从来都是能少一事则少一事,客户想要啥,给啥就好了,否则怕影响别的地方,毕竟都没时间精力测试……于是不光漏掉了 32 位内核的对应修改,而且应该是忘了改 glibc,因为直到 glibc 2.25 这个函数才被支持……最终加上 Gentoo 的 user-space,获得了一个四不像!
 
虽然两个地方对我都没影响,问题应该也不在龙芯团队头上,但怎么说都是有些蛋疼的感觉……看起来确乎有必要自己编译内核了 :joy:
 
另外也希望 Loongnix 尽量把自己的代码 upstream 吧,这样反而维护的人手能相当于多一些,况且 arch/mips 等等相关位置的改动所有人都看着,也不需要担心失去控制之类的。实际上,本人一直不是很理解为何一定要坚持自己维护单一一个版本,这主要是因为:
  1. 反正据本人了解,许多商业项目(以及龙芯公众可见的所有项目)都是 fork 一份代码出来,然后永远不管,就算提交到上游的代码被别人再怎么改,也不可能影响到项目;
  2. 维护单一一个版本造成研发人员思维僵化,永远不需要学习新版本的改动。短期来看可能省出了许多时间,但按照上述的“商业逻辑”,下一期项目一切从头评估,上游项目的版本往前推进了许多,这时候跟还是不跟?跟,所有更新版本的学习成本堆积在一起;不跟,最终系统的性能指标、安全漏洞最多跟以往一样,还不如从一开始就连二期都不做。
  3. upstreaming 短期来看也有许多成本,尤其像 Linux 这种协作流程有些奇葩的项目,加上龙芯的研发人员英语可能存在沟通障碍(看过 commit message 的人都懂,有些看得我尴尬癌都犯了,最关键最后还没看懂,连作者想说什么汉语都不知道……),upstreaming 可能受到阻碍。但是,这种成本很大程度上是一次性的,每个人只需要付出一遍,在整个几年甚至十几年的职业生涯中显得微乎其微。

 
说到这里,与国际社区的互动是确实有必要的。MIPS 生态本就式微,但仍然有一定体量。不能因为片面追求“全自主”就摈弃一切外界影响,何况由于上述的语言问题,龙芯的社区与国际社区存在信息不对称的现象。MIPS64r6、microMIPS 不支持就算了,自主指令集扩展文档不开放也就算了,GCC/LLVM 支持近乎为零也就算了,各种带汇编加塞儿的软件没有 MIPS/LoongISA 支持也就算了;目前龙芯生态系统建设中,危险的地方在于,国内有 push MIPS/Linux 生态的诉求,但国外的 MIPS 玩家根本感受不到。这使得外界的 MIPS 生态有崩塌的危险,万一发生了,我不认为当前只会 GNU/Linux 或者 Android 换个壳子的所谓“国产系统”能持续性地抵挡住外边的版本升级洪流而不掉队。(除非他们真的跟万年 XP 党一样,能够同一个系统永远不更新,一直用到死。现在看来,这种人还不少。)
 
何况还有各种带颜色的媒体报道,把单纯的建立独立于 Wintel 的另一极计算生态系统的想法无限政治化,殊不知使天下摆脱 Windows/Intel 垄断这件事如果能做成,这件事的意义中最不起眼的恰恰是政治意义!技术上的充分竞争促使商业上也充分竞争;大部分软件都一定要考虑跨平台互操作,对软件行业的良性发展有好处,甚至在未来可能发生下一次架构大迁徙之时,我们能够提前做好准备。至于政治上的自主可控,那不过是做了正确的事情之后,自然会具有的性质。所有国家都有权利建设自主的基础设施,当然也包括计算;因为我们是中国人,发出的声音自然是中国要做自己的 CPU,本身在当前美国本位的 IT 行业,你存在这件事情本身就是(他们的)政治化了,你在长大之前根本无法改变这个事实,只能在媒体报道中无限弱化它,让所有人都淡忘政治性的存在,直到终于成长起来,这时候再说什么都不迟。可惜的是现在国内一提龙芯就是自主可控,甚至还有一部分汉语编程党混进来,根本不提商业上打破垄断有多么深远的意义,宣传上不清楚还有什么好牌可以打了。
 
当然这些东西,我们作为社区开发者,也只能够描述一下见闻和思考;In the meantime,我还是去移植内核补丁了。这个 expat 编译错误以及调试它耗费的时间,最终我选择放弃这个 Loongnix 项目交付的产品;背后的东西,表明很多时候就算你做了很多事情,觉得自己很努力了,但实际上并一文不值。你要用正确的方式做事情才可以。
 
与君共勉。

内核4.10在龙芯3A3000笔记本上的移植(三)

zhouling 发表了文章 • 0 个评论 • 229 次浏览 • 2017-03-17 15:26 • 来自相关话题

系统再重启后,在我的 fedora25 上,有显示,但到了 udev Kernel Device Manager 这儿就开始报错,之后是一系列的报错,这跟 systemd 有关系,它需要内核  CONFIG_PACKET 和 CONFIG_INET 这两项都选上;这两项都勾选上,再编译下内核,重新安装模块和内核,生成 initrd 文件,再重启,应该就能看到图形的 login 界面了。 查看全部
系统再重启后,在我的 fedora25 上,有显示,但到了 udev Kernel Device Manager 这儿就开始报错,之后是一系列的报错,这跟 systemd 有关系,它需要内核  CONFIG_PACKET 和 CONFIG_INET 这两项都选上;这两项都勾选上,再编译下内核,重新安装模块和内核,生成 initrd 文件,再重启,应该就能看到图形的 login 界面了。

内核4.10在龙芯3A3000笔记本上的移植(二)

zhouling 发表了文章 • 5 个评论 • 205 次浏览 • 2017-03-17 15:10 • 来自相关话题

系统重启后,没有显示或者说是黑屏,解决办法:
把本文所附附件,解压,是一系列 patch(共 6 个),给 kernel 打完后(其中 0004-MIPS-Loogson-Make-enum-loongson_cpu_type-more-clear.patch 和 0005-MIPS-cpu_full_name-to-make-CPU-names-more-huma.patch 不打关系也不大,其余 4 个为必需),rebuild,  再安装模块、内核,重新生成 initrd 文件,再重启,应该会有显示了。 查看全部
系统重启后,没有显示或者说是黑屏,解决办法:
把本文所附附件,解压,是一系列 patch(共 6 个),给 kernel 打完后(其中 0004-MIPS-Loogson-Make-enum-loongson_cpu_type-more-clear.patch 和 0005-MIPS-cpu_full_name-to-make-CPU-names-more-huma.patch 不打关系也不大,其余 4 个为必需),rebuild,  再安装模块、内核,重新生成 initrd 文件,再重启,应该会有显示了。

内核4.10在龙芯3A3000笔记本上的移植(一)

zhouling 发表了文章 • 6 个评论 • 328 次浏览 • 2017-03-16 17:06 • 来自相关话题

1. 下载内核源码
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
此处下载的是 mainline 的所称为 vanilla 的内核源码

也可下载其它版本(如 stable 版)的源码,具体链接详见:
https://git.kernel.org/

2. 配置内核
   a) cd linux
   b) make mrproper
   c) 如果是想把内核安装到自己的系统上,建议使用已安装好的发行版拥有的配置文件,即:
      $ cp /boot/config-`uname -r` .config
      也可以:
      $ cp arch/mips/configs/loongson3_defconfig .config   *** 注意此处的 loongson3_defconfig 需先用
        http://www.loongnix.org/cgit/l ... figs/ 下的同名文件替换
   d) $ make menuconfig (运行此命令前需要有依赖包 ncurses-devel)
      此命令可以在当前(缺省)内核配置的基础上修改一些小地方,比如说新内核多了些新功能,而你想要用到它们,可以在这儿进行配置,然后生成新的内核配置文件

3. 编译内核
   $ make all 配置完后,就可以进行编译了
   说明一下,上述命令其实包括以下命令,即:
   $ make dep       确定依赖性
   $ make zImage    编译压缩内核
   $ make modules   生成内核模块

4. 在编译过程中,会遇到以下问题:
make[1]: *** No rule to make target 'firmware/radeon/BTC_rlc.bin', needed by 'firmware/radeon/BTC_rlc.bin.gen.o'。 停止。
Makefile:1002: recipe for target 'firmware' failed
make: *** [firmware] Error 2

   解决办法:从 http://www.loongnix.org/cgit/l ... adeon 链接拷贝以下文件到 firmware/radeon:

"BTC_rlc.bin CAICOS_mc.bin CAICOS_pfp.bin CAICOS_me.bin CAICOS_smc.bin SUMO_rlc.bin SUMO_pfp.bin SUMO_me.bin SUMO_uvd.bin SUMO2_me.bin SUMO2_pfp.bin CYPRESS_uvd.bin CEDAR_me.bin CEDAR_pfp.bin CEDAR_rlc.bin CYPRESS_me.bin CYPRESS_pfp.bin CYPRESS_rlc.bin JUNIPER_me.bin JUNIPER_pfp.bin JUNIPER_rlc.bin R600_rlc.bin R700_rlc.bin REDWOOD_me.bin REDWOOD_pfp.bin  RV710_pfp.bin RV710_me.bin TAHITI_uvd.bin PITCAIRN_pfp.bin PITCAIRN_me.bin PITCAIRN_ce.bin PITCAIRN_rlc.bin PITCAIRN_smc.bin PITCAIRN_mc.bin RV730_smc.bin RV710_uvd.bin BARTS_mc.bin BARTS_me.bin BARTS_pfp.bin BARTS_smc.bin TURKS_pfp.bin TURKS_me.bin TURKS_mc.bin RS780_me.bin RS780_pfp.bin RS780_uvd.bin TURKS_smc.bin"

5. 在编译中,可能会遇到:
  OBJCOPY arch/mips/boot/compressed/vmlinux.bin
  LZMA    arch/mips/boot/compressed/vmlinux.bin.z
/bin/sh: lzma: 未找到命令
arch/mips/boot/compressed/Makefile:70: recipe for target 'arch/mips/boot/compressed/vmlinux.bin.z' failed
make[1]: *** [arch/mips/boot/compressed/vmlinux.bin.z] Error 1
arch/mips/Makefile:377: recipe for target 'vmlinuz' failed
make: *** [vmlinuz] Error 2

  解决办法:安装 xz-lzma-compat 包   

编译完成后:
6. 安装模块
   $ sudo make modules_install

7. 安装内核
   $ sudo make install
 
8. 生成 initrd 文件
   $ sudo mkinitrd /boot/initramfs.4.10.0+ 4.10.0+    #后面的“4.10.0+”是在 /usr/lib/modules 目录下相应的目录名  
 
9. 更新 boot loader 相关配置文件,/boot/boot.cfg,添加下面内容,*** 注意是添加:
   title Fedora, with Linux 4.10.0+
   kernel (wd0,0)/boot/vmlinuz-4.10.0+
   initrd (wd0,0)/boot/initramfs-4.10.0+.img
   args root=UUID=414542a9-54f8-4c62-a500-6789dc759d05 rhgb quiet

10. 重启,测试新装内核 查看全部
1. 下载内核源码
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
此处下载的是 mainline 的所称为 vanilla 的内核源码

也可下载其它版本(如 stable 版)的源码,具体链接详见:
https://git.kernel.org/

2. 配置内核
   a) cd linux
   b) make mrproper
   c) 如果是想把内核安装到自己的系统上,建议使用已安装好的发行版拥有的配置文件,即:
      $ cp /boot/config-`uname -r` .config
      也可以:
      $ cp arch/mips/configs/loongson3_defconfig .config   *** 注意此处的 loongson3_defconfig 需先用
        http://www.loongnix.org/cgit/l ... figs/ 下的同名文件替换
   d) $ make menuconfig (运行此命令前需要有依赖包 ncurses-devel)
      此命令可以在当前(缺省)内核配置的基础上修改一些小地方,比如说新内核多了些新功能,而你想要用到它们,可以在这儿进行配置,然后生成新的内核配置文件

3. 编译内核
   $ make all 配置完后,就可以进行编译了
   说明一下,上述命令其实包括以下命令,即:
   $ make dep       确定依赖性
   $ make zImage    编译压缩内核
   $ make modules   生成内核模块

4. 在编译过程中,会遇到以下问题:
make[1]: *** No rule to make target 'firmware/radeon/BTC_rlc.bin', needed by 'firmware/radeon/BTC_rlc.bin.gen.o'。 停止。
Makefile:1002: recipe for target 'firmware' failed
make: *** [firmware] Error 2

   解决办法:从 http://www.loongnix.org/cgit/l ... adeon 链接拷贝以下文件到 firmware/radeon:

"BTC_rlc.bin CAICOS_mc.bin CAICOS_pfp.bin CAICOS_me.bin CAICOS_smc.bin SUMO_rlc.bin SUMO_pfp.bin SUMO_me.bin SUMO_uvd.bin SUMO2_me.bin SUMO2_pfp.bin CYPRESS_uvd.bin CEDAR_me.bin CEDAR_pfp.bin CEDAR_rlc.bin CYPRESS_me.bin CYPRESS_pfp.bin CYPRESS_rlc.bin JUNIPER_me.bin JUNIPER_pfp.bin JUNIPER_rlc.bin R600_rlc.bin R700_rlc.bin REDWOOD_me.bin REDWOOD_pfp.bin  RV710_pfp.bin RV710_me.bin TAHITI_uvd.bin PITCAIRN_pfp.bin PITCAIRN_me.bin PITCAIRN_ce.bin PITCAIRN_rlc.bin PITCAIRN_smc.bin PITCAIRN_mc.bin RV730_smc.bin RV710_uvd.bin BARTS_mc.bin BARTS_me.bin BARTS_pfp.bin BARTS_smc.bin TURKS_pfp.bin TURKS_me.bin TURKS_mc.bin RS780_me.bin RS780_pfp.bin RS780_uvd.bin TURKS_smc.bin"

5. 在编译中,可能会遇到:
  OBJCOPY arch/mips/boot/compressed/vmlinux.bin
  LZMA    arch/mips/boot/compressed/vmlinux.bin.z
/bin/sh: lzma: 未找到命令
arch/mips/boot/compressed/Makefile:70: recipe for target 'arch/mips/boot/compressed/vmlinux.bin.z' failed
make[1]: *** [arch/mips/boot/compressed/vmlinux.bin.z] Error 1
arch/mips/Makefile:377: recipe for target 'vmlinuz' failed
make: *** [vmlinuz] Error 2

  解决办法:安装 xz-lzma-compat 包   

编译完成后:
6. 安装模块
   $ sudo make modules_install

7. 安装内核
   $ sudo make install
 
8. 生成 initrd 文件
   $ sudo mkinitrd /boot/initramfs.4.10.0+ 4.10.0+    #后面的“4.10.0+”是在 /usr/lib/modules 目录下相应的目录名  
 
9. 更新 boot loader 相关配置文件,/boot/boot.cfg,添加下面内容,*** 注意是添加:
   title Fedora, with Linux 4.10.0+
   kernel (wd0,0)/boot/vmlinuz-4.10.0+
   initrd (wd0,0)/boot/initramfs-4.10.0+.img
   args root=UUID=414542a9-54f8-4c62-a500-6789dc759d05 rhgb quiet

10. 重启,测试新装内核
内核问题