您尚未登录。

#1 Re: RISC-V » 与 ARM 相比,Risc-V 有多好? » 2022-05-30 11:46:32

arm只有商业供应商,不存在开源供应商;risc-v不仅有商业供应商,还有开源供应商。

开源供应商的好处是:芯片的硬件电路完全开源,软件设计有电路参考。无需签NDA保密协议,无需走人际关系,无需付费。你可以拿存在开源供应商这回事去砍价,现在结果是risc-v整个生态的授权费都不高。有社区的技术支持,社区软件(比如Linux)可以和社区合作,节省人力物力。
坏处是:开源供应商一般公开网表,落地到具体工艺的实现不是所有供应商都有。

商业供应商的好处是:通常有落地具体工艺的实现。如果给够钱,有足够的技术支持。如果给够钱,有配套软件。
坏处是:如果你是企业用户,要给够钱,要签NDA保密协议。由于买到电路之后禁止公开,无法获取社区支持。授权费通常不低。而且,通常只有合作的工艺厂能做这一款供应商的处理器核,否则还得自己布线。如果你是个人用户,你无法获得芯片的硬件电路,对有些硬件bug无从下手,只能走人际关系去问,导致社区支持会很不好(Linux也是社区合作的软件)。

#2 Re: RISC-V » 与 ARM 相比,Risc-V 有多好? » 2022-05-30 11:30:53

@mengxp
科学院的香山在一些工艺上已经流过片,网上的网图是开源的。加上别的开源微架构,已经比arm好太多了

#3 Re: 全志 SOC » 一个如何让你的客户必须从你这里购买主芯片新思路,抛砖引玉,探讨探讨。(不采用加密芯片的方案) » 2022-05-26 11:01:03

@xboot
这个想法没错,只能是厂家首先提供了才能用,厂家不提供就没辙。现有的芯片也满足这个规律

#4 Re: RISC-V » 自制小型操作系统内核nxos支持risc-v架构64位系统 » 2022-05-26 10:09:00

@jasonhu
1. 这一点其实与内核开发者关联很大,如果是跟着清华的rCore课做内核的,内核的开发语言是Rust语言,这时候反而装一个C的编译器就成负担了,C的编译器老是要配置,Rust不用,对新语言的开发者来说O开头的竞争品非常不好。如果你是Rust内核的开发者,你会发现C语言的开发环境极其复杂,还要配置,很麻烦,而直接用RustSBI编译环境就会很简单,还不用你配置,用了就知道。
2. 这里是资料:github.com/rustsbi/slides 。还有很多资料散落在项目的wiki里。
O开头那个SBI资料多是因为西数公司的商业宣传,尤其是19年有篇错漏百出的ppt,强行说“RISC-V必须和OpenSBI配套使用”,还指出所谓RISC-V的引导必须有4-5个级别,我在做Oreboot的时候就只有一个级别。它4-5个级别就导致开机时间甚至要一分钟左右,但是为啥它还推这一套呢,是因为OpenSBI项目是他们公司掌控的,所有贡献者都是他们的人,打压个竞争对手岂不是分分钟的事情(这也是为啥我要做RustSBI)。他们商业宣传(广告啊这些)导致去网上一搜资料全是他们的,即使事实上我的资料数量更多、质量还更好。
另外,我的文档全部是中文,国人看着更舒服,一目十行,巨快,很容易消化吸收,有问题直接发帖,我直接用中文交流,毫无障碍,而西数毕竟还是美国人的东西,就很语焉不详,英文很难阅读,很多工程师还得等翻译,文章里有啥不懂的,人家天高皇帝远,也没地方问。
3. 这一点我至少公开批评过全志、勘智和先楫,凭什么白白给美国公司送代码,反而自己人的项目就嘲讽和打压
不过确实很多嵌入式老厂对Rust是完全不懂,至少没有改变的勇气。而且risc-v固件和arm、x86不同,不是所谓“能用就行”,它是在内核后台保持运行的,具体看我的ppt。一个良好编写的引导程序,可以提高操作系统运行的效率。有学术论文,SBI固件可以实现内核调试和安全孤岛(也就是secure enclave)功能,硬要说的话就是arm里的el3和这个很像,这些功能都是opensbi不能提供的。况且,opensbi只支持SBI 0.2规范,而早就有SBI 1.0版本了,很多新内核都没法在0.2上跑(linux除外,不要和我说“linux还没升级”)。
随着时间流逝,仍然固守opensbi的厂商将无法运行这些逐步发展的新内核。

今天我翻了翻github,我的rustsbi在github有451个星,而o开头的sbi只有437个星,到底哪个软件好开发者还是会用脚投票的。西数那边反正都是成年人了,谁的软件好大家心里都清楚,但是他们的目的要把o开头的推广成唯一标准,如果他们成功了,risc-v将成为一个只是看似开放的指令集,因为不可缺少的sbi环节被西数一个商业公司垄断。我的rustsbi就是为了打破垄断,让risc-v真正成为一个开放的指令集而存在的。

#5 Re: 全志 SOC » 一个如何让你的客户必须从你这里购买主芯片新思路,抛砖引玉,探讨探讨。(不采用加密芯片的方案) » 2022-05-22 17:03:28

上层楼的做法代码可以完全提供给客户,不过它的机制是可以保证只有经销商签名的引导程序能用,不签名不能用。如果要进一步在屏幕上显示提示,这个因为是需要写代码(至少要操作屏幕的芯片外设)才能完成的功能,芯片里预留给经销商控制的代码有限。如果要专门增加一个经销商代码的flash,就有点增加芯片成本了。显示提示这种需求还得靠群友集思广益。

#6 Re: 全志 SOC » 一个如何让你的客户必须从你这里购买主芯片新思路,抛砖引玉,探讨探讨。(不采用加密芯片的方案) » 2022-05-22 16:44:54

上面那层楼我没有说清楚,讲一讲(后续芯片代数开始)具体的实现方案。

总的思路是使用多级证书。多级证书就是经销商拥有一个证书,厂商也有一个证书。经销商的证书是芯片厂商签名过的,芯片厂商会在ROM代码里用私钥验证,保证经销商证书是不能造假的。然后有买家要买芯片的时候,它的引导程序必须被经销商证书签名,然后签名要放在引导程序的固件开头。那我怎么知道是哪个经销商签名的引导程序呢?把经销商的证书写进efuse代码里就可以了。经销商发给客户的芯片都是写好自己的经销商证书的,不能修改。芯片开机时,厂商的ROM代码会直接验证固件开头,保证引导程序是efuse里给定的证书签名的,而且efuse里的经销商证书也是厂商验证因此是真实的。如果客户要换引导程序或者升级引导程序怎么办呢?客户把新版引导程序发给经销商,经销商签名,然后客户把签名放在引导程序之前镜像的开头就可以了。

厂商私钥验证部分的ROM代码不能读,而且必须使用时长无关的指令去验证,防止各种侧信道偷ROM数据的做法。比如可以用RISC-V的K指令集。私钥验证的ROM代码可以和其它的ROM代码分开设计,私钥验证的ROM禁止读取,但其它部分的ROM代码开放性要尽量强,方便开源社区做引导程序来做芯片生态,其它部分的ROM代码仍然可以读。

为什么不用直接签名,而用多级证书呢?首先直接签名会把收到的芯片和某一个引导程序捆绑。如果芯片买家要更新引导程序版本(修bug等等)或换自己的引导程序(实现TEE、软调试内核或特殊需求等等),即使你仍然用同一个密钥给它签名,得到的签名是不同的,它这批买的芯片就废了。如果换一个密钥给它签名,直接签名的方法就得换一批efuse的值才能达到换密钥的目的,买家就只能等下一批新签名的货到了才能用,然后如果又发现老版本的引导程序才是对的,又要换老efuse的芯片,这就子子孙孙无穷尽了,所以直接签名在商业上不是容易完成的做法。

落实到具体应用上,如果经销商担心自己的证书私钥泄露(不一定是通过芯片泄露的,也有可能是内鬼或者别的网络安全问题),可能会在上面的模型之后再增加一个证书级别。每个批次的经销商货源会使用一个证书,这样每给客户交付一批新的货,给客户的引导程序重新签名一次就可以了。如果证书私钥泄露了,最多导致这一批货的芯片可以被破解,而不会影响前序后续批次的所有产品。当产品序列结束现役(比如5年、10年时间等等),经销商可以把货源的私钥公开,允许开发者去hack这个批次的产品,进一步扩展经销商的销路。

当厂家交付开发用芯片时,efuse代码还没写入证书,也就是不需要签名引导程序就能运行。这时候开发者可以写进自己的证书,然后通过一个特殊的外设验证ROM签名是否成功,来作为开发时参照使用。芯片里”不能更改证书“的efuse位还是允许的。量产的芯片如果规定必须经过经销商,经销商再写入”不能更改证书“位来禁止更改证书,达到验证货源的目的。

#7 Re: 全志 SOC » 一个如何让你的客户必须从你这里购买主芯片新思路,抛砖引玉,探讨探讨。(不采用加密芯片的方案) » 2022-05-22 16:25:12

一开始想把引导程序签名进efuse然后验签,不过这个挡不住客户去用开源的引导程序)

不过我觉得除非ROM里有某种保证机制否则就比较难说了。除非芯片厂硬编码了或者efuse里预留了一组根证书进去,然后一级级签名,最后经销商签名之后程序才能跑,这才好说。我觉得操作系统内核以及以上的机制都不能解决这个问题,因为换内核、换tee这些路径只要理论上可行,在利益下就一定有人会去做。

然后就是防止伪造签名了,这点用一些生命周期里不会出问题的算法就可以。

#9 Re: RISC-V » 如何调试Starfive的JH7100 Visionfive板子? » 2022-05-20 19:46:43

xusiwei1236 说:

翻了一下JH7100 Data sheet,大核U74默认的JTAG口是GPIO0~4:
https://whycan.com/files/members/9377/jh7100_jtag.png

jtag当然是这几个脚,最关键的不是jtag在哪,而是里面的调试模块(debug module),jtag是debug transport,它只是一个途径,最终访问的是调试模块。
它的调试模块高度怀疑是加密的,如果属实,它会和原厂软件强捆绑,原厂不给软件就没有任何办法。

我问了一些原厂的工程师,基本都拿“jtag是这几个脚”糊弄我

#11 Re: RISC-V » 与 ARM 相比,Risc-V 有多好? » 2022-05-04 11:14:22

微架构通常是开源的!如果你在跑riscv程序时遇到了状况,你甚至可以直接翻芯片的源码,而不是对着语焉不详的手册去猜,或者走关系和arm公司的员工去确认

#12 Re: 技术人生/软件使用技巧/破解经验/技术吐槽/灌水 » 是时候告别CSDN了! » 2022-04-30 23:52:24

我也讨厌CSDN,它罪状有三:
1. 利用创作者的文章收费引流
2. 实为内容农场的所谓“内容聚合页”
3. 弹窗广告

自从CSDN管运营的那个位置换人之后我就再也不用了

#13 RISC-V » 如何调试Starfive的JH7100 Visionfive板子? » 2022-04-29 22:56:16

洛佳
回复: 3

我做了个专门的夹子。然后,JTAG能不能用是问题之一,我试了ft2232和jlink,莫名其妙的问题非常多。问题之二是RISC-V debug module。这个RISC-V确实有标准规定,但是有些厂家故意不符合标准,他们提供调试帮助还好,如果不提供,太噩梦了。
有人有这块板子成功调试的经验吗?

如果有人关心我在做什么的话:我这里参加项目的目标是做一个能完整启动linux的引导程序,详见:github.com/oreboot/oreboot 。首先,我要能从闪存启动,而这对闪存格式的了解是必须的,这又依赖于JTAG调试过程。
RISC-V的引导程序和别的架构很不同,是需要保持在操作系统后台运行的,权限比内核还高,所以安全性至关重要,会有自己编写的需求。而且RISC-V的引导程序可以用来调试内核,还能用来做TEE,就不是一个简单的(厂家只给的那一个)引导程序能代替的了。
为什么不用u-boot呢?它为了兼容别的架构,还要适配RISC-V的SBI标准(又加了一级引导),最终把引导链做得巨长,导致开机一次要至少一分钟,这就没法接受了。

如果有厂家在看这篇帖子:尽量增加rom程序的透明度!因为rom代码对引导程序开发至关重要,没有的话只能抓瞎。RISC-V下又不是厂家做一个就能包揽所有需求,厂家不能只做一个引导程序然后说:都用我的吧。其实相当于啥也没给
如果rom里有产权代码:去掉这些代码就行了,或者分割成两个项目。我们又不要求源码能编译,相反,能看懂就行。

还有:有朋友告诉我,RISC-V的调试模块没有arm公司严格规定,它甚至可以做成加密的。然而如果厂商这么做了,我认为这是在选择彻底和开源社区决裂,这就是另一个话题了。

#14 全志 SOC » 我在做一个很小的D1 SPL » 2022-04-17 10:41:20

洛佳
回复: 0

链接: https://github.com/luojia65/test-d1-flash-bare
可以在任何平台上编译,无论linux,Windows或者mac。

这个项目是给oreboot引导程序准备的

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn