Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 09/11/2018 08:16 AM, Rudolf Marek wrote: > Hi, > > Sifive did great job [1] [2] and everything is now opensource including mask > rom loader. Nice! Truly a win for freedom hardware Lets hope they next add an IOMMU. > > "Today we’re finally able to rectify this issue by releasing the FU540-C000’s > ZSBL and FSBL as an open source project, which can be found on GitHub like > all of SiFive’s other open source projects." > > And I guess someone could be interested in: > > "A Challenge > > Now that the bootloader code has been released it’s time for a little > challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no > way to replace it, but you can at least re-generate the contents of the ROM > and then verify that it matches the contents of a real HiFive Unleashed. > We’ve posted a copy of the contents of the mask ROM at > https://github.com/sifive/freedom-u540-c000-bootloader, the first person to > submit a pull request that can exactly reproduce that ROM will get a HiFive > Unleashed board!" Sweet :D I am trying that for sure! https://github.com/sifive/freedom-u540-c000-bootloader/tree/challenge/u540-c000-release Here is a linky to the actual mask rom for lazy people. > > Thanks > Rudolf > > > [1] > https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom-u540-c000s-bootloader/ > [2] https://github.com/sifive/freedom-u540-c000-bootloader > > > 0xDF372A17.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
It looks like someone already pulled it off :[ https://github.com/sifive/freedom-u540-c000-bootloader/pull/6 0xDF372A17.asc Description: application/pgp-keys -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi, Sifive did great job [1] [2] and everything is now opensource including mask rom loader. "Today we’re finally able to rectify this issue by releasing the FU540-C000’s ZSBL and FSBL as an open source project, which can be found on GitHub like all of SiFive’s other open source projects." And I guess someone could be interested in: "A Challenge Now that the bootloader code has been released it’s time for a little challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no way to replace it, but you can at least re-generate the contents of the ROM and then verify that it matches the contents of a real HiFive Unleashed. We’ve posted a copy of the contents of the mask ROM at https://github.com/sifive/freedom-u540-c000-bootloader, the first person to submit a pull request that can exactly reproduce that ROM will get a HiFive Unleashed board!" Thanks Rudolf [1] https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom-u540-c000s-bootloader/ [2] https://github.com/sifive/freedom-u540-c000-bootloader -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
That document is very useful. Nice to see SiFive came through :-) -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi all See [1] > terpstraWesley W. TerpstraVerified SiFive Account > 2d > > I saw a few posts on the internet, which misrepresented what I was > expressing. I never suggested reverse engineering our partner’s IP! > > SiFive is committed to supporting the open-source community. We are pleased > to report that after discussions with our IP partners, we are now able to > make available all the source code required to initialize the HiFive > Unleashed board. The board’s boot sequence is described in the manual. The > assembly code in the initial reset ROM is listed in the manual Chapter 6.1 > “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by > software on the chip, and we will be making the full source code available > shortly. The source code for FSBL including the DDR initialization will also > be available shortly. We can attest there is no other firmware run by the > system during boot. And yes there is at least a chapter 20.3 Reset and Initialization in [2], which boils down of taking stuff out of reset, programming clocks and sets all values. Thanks Rudolf [1] https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/8 [2] https://static.dev.sifive.com/FU540-C000-v1.0.pdf now. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Mon, Jun 25, 2018 at 11:39 PM, ron minnich wrote: > > > On Mon, Jun 25, 2018 at 12:55 AM Shawn wrote: >> >> Hi Ron, >> >> >> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. >> But it can do more than what SMM does. > > > that's in my view not good, since in many cases, M mode code is part of > firmware, not the kernel image. Kernels don't get to change or ignore it. M > mode can protect itself from the kernel, even from being read. So it can > hide its presence, what it does, and might even be able to change itself. > > I had a talk with a BIG ARM SOC vendor not long ago. They said that at one > point a big x86 company proposed that their company implement SMM for ARM. > "so they asked us to implement this SMM-like thing that had unlimited > privilege. We said no, no no, there's no reason to repeat x86 mistakes on > ARM". Good call on that company's part. > > I argued several years ago that M mode code should be supplied by the > kernel, not firmware, for the obvious reasons: M mode is a great place to > put a persistent threat. The various x86 experiences were well known by that > time, so the problem should have been pretty clear. > Well, from that perspective I'm totally agree w/ SMM is a big threat especially when the machine was compromised and then attacker implant a rootkit running in SMM. If that happened in x86, it's pretty much fuc*ed up. Cu'z it's unlikely detect the smm rootkit at runtime, while the static analysis of forensics cost more time/money. Maybe we should've taken mitigation( SMRAM?) into this case in the 1st place. -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Tue, Jun 26, 2018 at 12:01 AM, Nico Huber wrote: > On 25.06.2018 09:55, Shawn wrote:> Hi Ron, >> On Sun, Jun 24, 2018 at 12:55 AM, ron minnich wrote: >>> On Wed, Jun 20, 2018 at 11:03 PM taii...@gmx.com wrote: Whats the deal with SMM? What a shame they thought to add it. >>> >>> It's a huge disappointment. I made some effort a few years ago to try to >>> convince folks this was a bad idea and failed. >>> >>> I'm no longer as optimistic as I was about RISC-V. There seems to be a real >>> push to be "just like x86". >> >> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. >> But it can do more than what SMM does. It helps to enclave-based >> solution. I'm looking forward to see the open solution, e.g: Sanctum, >> Keystone, etc to land into production environment. > > IMO, putting enclaves on the same silicon as the code you want to > protect them from is a failed concept. And more, it's bullshit, it > means two separate entities have to own the same physical chip. And > SGX proves that it doesn't work (they can't protect the OS from being > spied upon from the enclave (see Spectre), how can they ever hope to > protect the enclave from the much more powerful OS?). > SGX get rids of the major attack surfaces but a few left( unfortunately, side-channel is one of them). Speaking of "two separate entities have to own the same physical chip", yes and no, IIRC SGX is highly rely on some ME code modules( EPID?) which supposed to be running in another chip. IMOHO, what SGX's problem is that it's not an open solution and it can't be audited properly. It doesn't mean we( RSIC-V?) can't learn anything from it. > IMHO, not RISC-V but the whole industry is at least 20 years away from > getting that going (software separation in one piece of silicon, with- > out help from the software). > > So, no, no marketing false-security tech* that doesn't provide what it > promises can justify to pollute an architecture like RISC-V. > > Nico > > * I know there is a lot of honest research around enclaves, but they > all seem to ignore the reality of today's processors. > Well, diff ppl has different requirements. The current status of enclave is not good as expected. It may or may not improve in the future. -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi, Dne 25.6.2018 v 09:01 Jonathan Neuschäfer napsal(a): > If this is the Denali DDR controller, do you think it would be possible > to simply read the initial configuration out of the registers of a > booted system? (In any case, that's probably worth trying.) Perhaps it could work with the existing coreboot code. Basically it seems the PHY addresses are just black boxes and the configuration is mostly black box. Plus some logic is needed. See rockchip/rk3399/sdram.c Maybe some bits needs to be initially 0, and written later. Another suspicious coincidence that it is denali is this: /* * work around controller bug: * Do not program DRAM_CLASS until NO_PHY_IND_TRAIN_INT is programmed */ copy_to_reg(_ctl[1], _ctl[1], sizeof(struct rk3399_ddr_pctl_regs) - 4); write32(_ctl[0], params_ctl[0]); You see, it writes the first register last. As the DRAM_CLASS is defined to be first register in sifive manual in bits 11:8. The LPDDR3 seems to be 6 in coreboot sources, and the sifive manual says DDR3 is 6 and DDR4 is 0xa which matches and also bit position seems to match! There is also some denali support in the u-boot it seems. Plus this seems to be some old iteration: http://www.fujitsu.com/downloads/MICRO/fme/displaycontrollers/rd-mb86r12-emerald-p-register-rev0-04.pdf Seems to document some of it. Search terms: "denali" "CASLAT_LIN" or "denali" "dram_class" Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Mon, Jun 25, 2018 at 8:46 AM Peter Stuge wrote: > ron minnich wrote: > > I realize there was a lot of hope in the early days that RISC-V > > implied "openness" but as we can see that is not so. > > I hope that noone had that impression. > Lots of people have had that impression, hence my attempts over the years to point out it was wrong. And yet lots of people still think that "free instruction set" means "no blobs". And, as you have also pointed out frequently, that's not how it works ... thanks ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 25.06.2018 09:55, Shawn wrote:> Hi Ron, > On Sun, Jun 24, 2018 at 12:55 AM, ron minnich wrote: >> On Wed, Jun 20, 2018 at 11:03 PM taii...@gmx.com wrote: >>> Whats the deal with SMM? What a shame they thought to add it. >> >> It's a huge disappointment. I made some effort a few years ago to try to >> convince folks this was a bad idea and failed. >> >> I'm no longer as optimistic as I was about RISC-V. There seems to be a real >> push to be "just like x86". > > IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. > But it can do more than what SMM does. It helps to enclave-based > solution. I'm looking forward to see the open solution, e.g: Sanctum, > Keystone, etc to land into production environment. IMO, putting enclaves on the same silicon as the code you want to protect them from is a failed concept. And more, it's bullshit, it means two separate entities have to own the same physical chip. And SGX proves that it doesn't work (they can't protect the OS from being spied upon from the enclave (see Spectre), how can they ever hope to protect the enclave from the much more powerful OS?). IMHO, not RISC-V but the whole industry is at least 20 years away from getting that going (software separation in one piece of silicon, with- out help from the software). So, no, no marketing false-security tech* that doesn't provide what it promises can justify to pollute an architecture like RISC-V. Nico * I know there is a lot of honest research around enclaves, but they all seem to ignore the reality of today's processors. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/25/2018 10:45 AM, Peter Stuge wrote: > ron minnich wrote: >> I realize there was a lot of hope in the early days that RISC-V >> implied "openness" but as we can see that is not so. > > I hope that noone had that impression. > > The key point (which I have to repeat every now and then) is that > RISC-V *supports* openness, in ways not possible with x86, ARM or > -yes- even POWER, at least at the moment. > > >> An open implementation of RISC-V will require a commitment on the >> part of a company to opening it up at all levels, not just the >> instruction set. > > ron minnich wrote: >> I'm still interested in risc-v, just not hifive. > > Right - I think it's important not to judge an open architecture by > any one implementation, but to remember (as you point out) the > difference between architecture and implementation. > > > //Peter > The problem as I see it is that the two are inextricably tied. You can have a completely open architecture and no open implementations -- in fact, this is the case right now with the Sparc T2. I can run the HDL on an FPGA or even fab a chip with the right resources, but there is no reason to actually fab a chip, nor do I personally have the resources to do so. In practice, publicly available implementations are what determine the actual openness of an architecture. Compared to fab and design costs, everything else is nearly a rounding error. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
ron minnich wrote: > I realize there was a lot of hope in the early days that RISC-V > implied "openness" but as we can see that is not so. I hope that noone had that impression. The key point (which I have to repeat every now and then) is that RISC-V *supports* openness, in ways not possible with x86, ARM or -yes- even POWER, at least at the moment. > An open implementation of RISC-V will require a commitment on the > part of a company to opening it up at all levels, not just the > instruction set. ron minnich wrote: > I'm still interested in risc-v, just not hifive. Right - I think it's important not to judge an open architecture by any one implementation, but to remember (as you point out) the difference between architecture and implementation. //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Mon, Jun 25, 2018 at 12:55 AM Shawn wrote: > Hi Ron, > > > IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. > But it can do more than what SMM does. > that's in my view not good, since in many cases, M mode code is part of firmware, not the kernel image. Kernels don't get to change or ignore it. M mode can protect itself from the kernel, even from being read. So it can hide its presence, what it does, and might even be able to change itself. I had a talk with a BIG ARM SOC vendor not long ago. They said that at one point a big x86 company proposed that their company implement SMM for ARM. "so they asked us to implement this SMM-like thing that had unlimited privilege. We said no, no no, there's no reason to repeat x86 mistakes on ARM". Good call on that company's part. I argued several years ago that M mode code should be supplied by the kernel, not firmware, for the obvious reasons: M mode is a great place to put a persistent threat. The various x86 experiences were well known by that time, so the problem should have been pretty clear. That's another point I somehow failed to communicate well, since I was ignored. Hence, RISC-V now comes with Persistent Threat Support (TM) for free :-( ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi Ron, On Sun, Jun 24, 2018 at 12:55 AM, ron minnich wrote: > > > On Wed, Jun 20, 2018 at 11:03 PM taii...@gmx.com wrote: >> >> >> >> Whats the deal with SMM? What a shame they thought to add it. >> >> > > > It's a huge disappointment. I made some effort a few years ago to try to > convince folks this was a bad idea and failed. > > I'm no longer as optimistic as I was about RISC-V. There seems to be a real > push to be "just like x86". > IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. But it can do more than what SMM does. It helps to enclave-based solution. I'm looking forward to see the open solution, e.g: Sanctum, Keystone, etc to land into production environment. btw: can't agree w/ you more about we need more open implementation than Hifive unleashed. [1] Secure Processors Part I: Background, Taxonomy for Secure Enclaves and Intel SGX Architecture: https://people.csail.mit.edu/devadas/pubs/part_1.pdf [2] Secure Processors Part II: Intel SGX Security Analysis and MIT Sanctum Architecture: https://people.csail.mit.edu/devadas/pubs/part_2.pdf [3] Keystone: https://keystone-enclave.org/ -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/25/2018 02:30 AM, Timothy Pearson wrote: > On 06/24/2018 08:06 PM, Nico Huber wrote: >> On 25.06.2018 01:55, Timothy Pearson wrote: >>> On 06/24/2018 06:41 PM, Timothy Pearson wrote: On 06/24/2018 06:35 PM, Nico Huber wrote: > On 24.06.2018 23:52, Timothy Pearson wrote: >> On 06/24/2018 03:43 PM, Nico Huber wrote: >>> On 24.06.2018 21:37, taii...@gmx.com wrote: On 06/24/2018 02:59 PM, ron minnich wrote: > On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer > > wrote: > >> >> >> "While we’d love to provide you with this information, we believe we >> cannot. However, we can’t prevent anyone from disassembling the fsbl >> and >> copying the values sent to the blackbox DDR register map." >> >> > > and ... there ends my interest in the hifive. A shame. > I can't understand what their target audience is? who would buy such a thing? who do they intend to sell these to? I mean the open source people can buy the now very affordable Talos 2L and the cheap-soc people can buy one of the many of ARM boards that litter the marketplace...I don't get it. >>> >>> I don't think you can compare the HiFive Unleashed with the Talos. They >>> really target completely different people and use cases. You could as >>> well ask, why produce smart watches, when people can afford the Talos? >>> >>> Talos is a workstation it doesn't fit anywhere but a workplace where >>> somebody else pays the power bill. So you can't even compare it to >>> cheap ARM SBCs, HiFive aside. It's a professional product, nothing to >>> play with, but something to work with. And it's open. It is marketed >>> as open. It is designed to be open. It is based on an open platform. >> >> I just want to counter this one point. POWER9 is absolutely not power >> hungry. I've seen the 8-core chips idle at under 10W, with active loads >> maybe in the 40-60W range. We're dogfooding one machine in a typical >> office setting, and it dissipates nearly no heat -- it's using less >> power than the older Xeon it replaced. > > Hmmm, yeah, just twist my words as you wish. I never said that it is > power hungry compared to other workstation systems. I did not even state > that it is power hungry at all. All I said is that it needs power and > somebody has to pay for that too. > > Now you show off with random numbers that make things really weird. 10W > for what? per chip? or per core? Whatever it is, I hope your office has > air conditioning. And than that "it's using less power than the older > Xeon", omg really? you're system is better than shit? > > Nico Did not mean to offend here. Apparently we have very different ideas of "workstation" versus "desktop"; we'd classify some dozens of watts under real world load per CPU as a desktop, not as a workstation per se. I don't see how something using this little power would suddenly put the power bills out of reach for individual use vs. corporate use, but again we may have very different ideas of what a computer should be. Personally, I would never be able to use something like a Raspberry Pi or other low power SBC for anything other than maybe some minimal text editing. It's not worth my time to put up with a slow, unresponsive system; whatever I would gain on power bills would be lost through unproductive time and then some. I don't see how providing some real world numbers can be frowned upon here? >>> >>> >>> So it was pointed out to me on IRC that we don't have current power >>> numbers published on the Wiki. That would probably explain the >>> confusion; subsequent firmware updates have dropped the idle power and >>> "normal use" power significantly on the POWER9 chips. >> >> Sorry, I really still had the wiki numbers in mind (> 100W idle). Which >> would be notable on a power bill. And then, 10W per 8 core CPU really >> confused me (with 30W for the 4 core CPU in mind I really anticipated >> you mean 10W per core). So it can compete with today's average desktop >> system wrt. idle power. This makes the Talos II even more attractive now >> (and I'm thinking about the space below my desk again). >> >>> >>> I'll see if we can get some new at-wall measurements of our normal >>> desktop configuration (1 CPU, no SAS, NVMe storage). This should be >>> well under 100W at the wall. >> >> I'm really happily surprised by the new numbers. If you keep the max. >> below 160W, you could sell it with a Pico-PSU ;) > > Just got done doing some initial checks on a Lite system (4 cores, 2x > 16GB ECC registered DIMMs, 1TB NVMe drive). Actually having some > measurement issues due to how low the DC side load is -- the board
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Mon, Jun 25, 2018 at 2:46 AM, Jonathan Neuschäfer wrote: > On Fri, Jun 22, 2018 at 01:01:04PM +0200, Jonathan Neuschäfer wrote: > [...] >> Section 20.3 describes the initialization sequence for the DRAM >> controller, but leaves out the values for the register for "memory >> timing settings, PAD mode configuration, initialization, and training." >> It says: "Please contact SiFive directly to determine the complete >> register settings for your application." >> >> I will ask on the forum. > > "While we’d love to provide you with this information, we believe we > cannot. However, we can’t prevent anyone from disassembling the fsbl and > copying the values sent to the blackbox DDR register map." > (-- > https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/3) > Thanks, seems our only option is to reversing. -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/24/2018 08:06 PM, Nico Huber wrote: > On 25.06.2018 01:55, Timothy Pearson wrote: >> On 06/24/2018 06:41 PM, Timothy Pearson wrote: >>> On 06/24/2018 06:35 PM, Nico Huber wrote: On 24.06.2018 23:52, Timothy Pearson wrote: > On 06/24/2018 03:43 PM, Nico Huber wrote: >> On 24.06.2018 21:37, taii...@gmx.com wrote: >>> On 06/24/2018 02:59 PM, ron minnich wrote: On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer wrote: > > > "While we’d love to provide you with this information, we believe we > cannot. However, we can’t prevent anyone from disassembling the fsbl > and > copying the values sent to the blackbox DDR register map." > > and ... there ends my interest in the hifive. A shame. >>> >>> I can't understand what their target audience is? who would buy such a >>> thing? who do they intend to sell these to? I mean the open source >>> people can buy the now very affordable Talos 2L and the cheap-soc people >>> can buy one of the many of ARM boards that litter the marketplace...I >>> don't get it. >> >> I don't think you can compare the HiFive Unleashed with the Talos. They >> really target completely different people and use cases. You could as >> well ask, why produce smart watches, when people can afford the Talos? >> >> Talos is a workstation it doesn't fit anywhere but a workplace where >> somebody else pays the power bill. So you can't even compare it to >> cheap ARM SBCs, HiFive aside. It's a professional product, nothing to >> play with, but something to work with. And it's open. It is marketed >> as open. It is designed to be open. It is based on an open platform. > > I just want to counter this one point. POWER9 is absolutely not power > hungry. I've seen the 8-core chips idle at under 10W, with active loads > maybe in the 40-60W range. We're dogfooding one machine in a typical > office setting, and it dissipates nearly no heat -- it's using less > power than the older Xeon it replaced. Hmmm, yeah, just twist my words as you wish. I never said that it is power hungry compared to other workstation systems. I did not even state that it is power hungry at all. All I said is that it needs power and somebody has to pay for that too. Now you show off with random numbers that make things really weird. 10W for what? per chip? or per core? Whatever it is, I hope your office has air conditioning. And than that "it's using less power than the older Xeon", omg really? you're system is better than shit? Nico >>> >>> >>> Did not mean to offend here. Apparently we have very different ideas of >>> "workstation" versus "desktop"; we'd classify some dozens of watts under >>> real world load per CPU as a desktop, not as a workstation per se. I >>> don't see how something using this little power would suddenly put the >>> power bills out of reach for individual use vs. corporate use, but again >>> we may have very different ideas of what a computer should be. >>> >>> Personally, I would never be able to use something like a Raspberry Pi >>> or other low power SBC for anything other than maybe some minimal text >>> editing. It's not worth my time to put up with a slow, unresponsive >>> system; whatever I would gain on power bills would be lost through >>> unproductive time and then some. >>> >>> I don't see how providing some real world numbers can be frowned upon here? >>> >> >> >> So it was pointed out to me on IRC that we don't have current power >> numbers published on the Wiki. That would probably explain the >> confusion; subsequent firmware updates have dropped the idle power and >> "normal use" power significantly on the POWER9 chips. > > Sorry, I really still had the wiki numbers in mind (> 100W idle). Which > would be notable on a power bill. And then, 10W per 8 core CPU really > confused me (with 30W for the 4 core CPU in mind I really anticipated > you mean 10W per core). So it can compete with today's average desktop > system wrt. idle power. This makes the Talos II even more attractive now > (and I'm thinking about the space below my desk again). > >> >> I'll see if we can get some new at-wall measurements of our normal >> desktop configuration (1 CPU, no SAS, NVMe storage). This should be >> well under 100W at the wall. > > I'm really happily surprised by the new numbers. If you keep the max. > below 160W, you could sell it with a Pico-PSU ;) Just got done doing some initial checks on a Lite system (4 cores, 2x 16GB ECC registered DIMMs, 1TB NVMe drive). Actually having some measurement issues due to how low the DC side load is -- the board only "wants" 50 watts or so at idle, but the Seasonic 1200W Platinum supply being used has terrible efficiency in that range, resulting in at-wall
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Sun, Jun 24, 2018 at 11:28:11PM +0200, Rudolf Marek wrote: > Hi, > > Lets do some speculation that some off the shelf DDR memory controller is > used. Probably. > Maybe it could be same as the RockChip aka Denali High-Speed DDR PHY IP from > Cadence? > It has also some "interrupt status" bits and such and "bstlen" which sounds > same as the few > regs named as the documentation. I haven't compared the register maps, and I'm not familiar with other controllers, this sounds like a good lead. If this is the Denali DDR controller, do you think it would be possible to simply read the initial configuration out of the registers of a booted system? (In any case, that's probably worth trying.) Jonathan Neuschäfer signature.asc Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 25.06.2018 01:55, Timothy Pearson wrote: > On 06/24/2018 06:41 PM, Timothy Pearson wrote: >> On 06/24/2018 06:35 PM, Nico Huber wrote: >>> On 24.06.2018 23:52, Timothy Pearson wrote: On 06/24/2018 03:43 PM, Nico Huber wrote: > On 24.06.2018 21:37, taii...@gmx.com wrote: >> On 06/24/2018 02:59 PM, ron minnich wrote: >>> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >>> >>> wrote: >>> "While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map." >>> >>> and ... there ends my interest in the hifive. A shame. >>> >> >> I can't understand what their target audience is? who would buy such a >> thing? who do they intend to sell these to? I mean the open source >> people can buy the now very affordable Talos 2L and the cheap-soc people >> can buy one of the many of ARM boards that litter the marketplace...I >> don't get it. > > I don't think you can compare the HiFive Unleashed with the Talos. They > really target completely different people and use cases. You could as > well ask, why produce smart watches, when people can afford the Talos? > > Talos is a workstation it doesn't fit anywhere but a workplace where > somebody else pays the power bill. So you can't even compare it to > cheap ARM SBCs, HiFive aside. It's a professional product, nothing to > play with, but something to work with. And it's open. It is marketed > as open. It is designed to be open. It is based on an open platform. I just want to counter this one point. POWER9 is absolutely not power hungry. I've seen the 8-core chips idle at under 10W, with active loads maybe in the 40-60W range. We're dogfooding one machine in a typical office setting, and it dissipates nearly no heat -- it's using less power than the older Xeon it replaced. >>> >>> Hmmm, yeah, just twist my words as you wish. I never said that it is >>> power hungry compared to other workstation systems. I did not even state >>> that it is power hungry at all. All I said is that it needs power and >>> somebody has to pay for that too. >>> >>> Now you show off with random numbers that make things really weird. 10W >>> for what? per chip? or per core? Whatever it is, I hope your office has >>> air conditioning. And than that "it's using less power than the older >>> Xeon", omg really? you're system is better than shit? >>> >>> Nico >> >> >> Did not mean to offend here. Apparently we have very different ideas of >> "workstation" versus "desktop"; we'd classify some dozens of watts under >> real world load per CPU as a desktop, not as a workstation per se. I >> don't see how something using this little power would suddenly put the >> power bills out of reach for individual use vs. corporate use, but again >> we may have very different ideas of what a computer should be. >> >> Personally, I would never be able to use something like a Raspberry Pi >> or other low power SBC for anything other than maybe some minimal text >> editing. It's not worth my time to put up with a slow, unresponsive >> system; whatever I would gain on power bills would be lost through >> unproductive time and then some. >> >> I don't see how providing some real world numbers can be frowned upon here? >> > > > So it was pointed out to me on IRC that we don't have current power > numbers published on the Wiki. That would probably explain the > confusion; subsequent firmware updates have dropped the idle power and > "normal use" power significantly on the POWER9 chips. Sorry, I really still had the wiki numbers in mind (> 100W idle). Which would be notable on a power bill. And then, 10W per 8 core CPU really confused me (with 30W for the 4 core CPU in mind I really anticipated you mean 10W per core). So it can compete with today's average desktop system wrt. idle power. This makes the Talos II even more attractive now (and I'm thinking about the space below my desk again). > > I'll see if we can get some new at-wall measurements of our normal > desktop configuration (1 CPU, no SAS, NVMe storage). This should be > well under 100W at the wall. I'm really happily surprised by the new numbers. If you keep the max. below 160W, you could sell it with a Pico-PSU ;) Nico PS. Trying to shut up now, enough OT. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/24/2018 06:41 PM, Timothy Pearson wrote: > On 06/24/2018 06:35 PM, Nico Huber wrote: >> On 24.06.2018 23:52, Timothy Pearson wrote: >>> On 06/24/2018 03:43 PM, Nico Huber wrote: On 24.06.2018 21:37, taii...@gmx.com wrote: > On 06/24/2018 02:59 PM, ron minnich wrote: >> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >> >> wrote: >> >>> >>> >>> "While we’d love to provide you with this information, we believe we >>> cannot. However, we can’t prevent anyone from disassembling the fsbl and >>> copying the values sent to the blackbox DDR register map." >>> >>> >> >> and ... there ends my interest in the hifive. A shame. >> > > I can't understand what their target audience is? who would buy such a > thing? who do they intend to sell these to? I mean the open source > people can buy the now very affordable Talos 2L and the cheap-soc people > can buy one of the many of ARM boards that litter the marketplace...I > don't get it. I don't think you can compare the HiFive Unleashed with the Talos. They really target completely different people and use cases. You could as well ask, why produce smart watches, when people can afford the Talos? Talos is a workstation it doesn't fit anywhere but a workplace where somebody else pays the power bill. So you can't even compare it to cheap ARM SBCs, HiFive aside. It's a professional product, nothing to play with, but something to work with. And it's open. It is marketed as open. It is designed to be open. It is based on an open platform. >>> >>> I just want to counter this one point. POWER9 is absolutely not power >>> hungry. I've seen the 8-core chips idle at under 10W, with active loads >>> maybe in the 40-60W range. We're dogfooding one machine in a typical >>> office setting, and it dissipates nearly no heat -- it's using less >>> power than the older Xeon it replaced. >> >> Hmmm, yeah, just twist my words as you wish. I never said that it is >> power hungry compared to other workstation systems. I did not even state >> that it is power hungry at all. All I said is that it needs power and >> somebody has to pay for that too. >> >> Now you show off with random numbers that make things really weird. 10W >> for what? per chip? or per core? Whatever it is, I hope your office has >> air conditioning. And than that "it's using less power than the older >> Xeon", omg really? you're system is better than shit? >> >> Nico > > > Did not mean to offend here. Apparently we have very different ideas of > "workstation" versus "desktop"; we'd classify some dozens of watts under > real world load per CPU as a desktop, not as a workstation per se. I > don't see how something using this little power would suddenly put the > power bills out of reach for individual use vs. corporate use, but again > we may have very different ideas of what a computer should be. > > Personally, I would never be able to use something like a Raspberry Pi > or other low power SBC for anything other than maybe some minimal text > editing. It's not worth my time to put up with a slow, unresponsive > system; whatever I would gain on power bills would be lost through > unproductive time and then some. > > I don't see how providing some real world numbers can be frowned upon here? > So it was pointed out to me on IRC that we don't have current power numbers published on the Wiki. That would probably explain the confusion; subsequent firmware updates have dropped the idle power and "normal use" power significantly on the POWER9 chips. I'll see if we can get some new at-wall measurements of our normal desktop configuration (1 CPU, no SAS, NVMe storage). This should be well under 100W at the wall. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/24/2018 06:35 PM, Nico Huber wrote: > On 24.06.2018 23:52, Timothy Pearson wrote: >> On 06/24/2018 03:43 PM, Nico Huber wrote: >>> On 24.06.2018 21:37, taii...@gmx.com wrote: On 06/24/2018 02:59 PM, ron minnich wrote: > On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer > > wrote: > >> >> >> "While we’d love to provide you with this information, we believe we >> cannot. However, we can’t prevent anyone from disassembling the fsbl and >> copying the values sent to the blackbox DDR register map." >> >> > > and ... there ends my interest in the hifive. A shame. > I can't understand what their target audience is? who would buy such a thing? who do they intend to sell these to? I mean the open source people can buy the now very affordable Talos 2L and the cheap-soc people can buy one of the many of ARM boards that litter the marketplace...I don't get it. >>> >>> I don't think you can compare the HiFive Unleashed with the Talos. They >>> really target completely different people and use cases. You could as >>> well ask, why produce smart watches, when people can afford the Talos? >>> >>> Talos is a workstation it doesn't fit anywhere but a workplace where >>> somebody else pays the power bill. So you can't even compare it to >>> cheap ARM SBCs, HiFive aside. It's a professional product, nothing to >>> play with, but something to work with. And it's open. It is marketed >>> as open. It is designed to be open. It is based on an open platform. >> >> I just want to counter this one point. POWER9 is absolutely not power >> hungry. I've seen the 8-core chips idle at under 10W, with active loads >> maybe in the 40-60W range. We're dogfooding one machine in a typical >> office setting, and it dissipates nearly no heat -- it's using less >> power than the older Xeon it replaced. > > Hmmm, yeah, just twist my words as you wish. I never said that it is > power hungry compared to other workstation systems. I did not even state > that it is power hungry at all. All I said is that it needs power and > somebody has to pay for that too. > > Now you show off with random numbers that make things really weird. 10W > for what? per chip? or per core? Whatever it is, I hope your office has > air conditioning. And than that "it's using less power than the older > Xeon", omg really? you're system is better than shit? > > Nico Did not mean to offend here. Apparently we have very different ideas of "workstation" versus "desktop"; we'd classify some dozens of watts under real world load per CPU as a desktop, not as a workstation per se. I don't see how something using this little power would suddenly put the power bills out of reach for individual use vs. corporate use, but again we may have very different ideas of what a computer should be. Personally, I would never be able to use something like a Raspberry Pi or other low power SBC for anything other than maybe some minimal text editing. It's not worth my time to put up with a slow, unresponsive system; whatever I would gain on power bills would be lost through unproductive time and then some. I don't see how providing some real world numbers can be frowned upon here? -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 24.06.2018 23:52, Timothy Pearson wrote: > On 06/24/2018 03:43 PM, Nico Huber wrote: >> On 24.06.2018 21:37, taii...@gmx.com wrote: >>> On 06/24/2018 02:59 PM, ron minnich wrote: On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer wrote: > > > "While we’d love to provide you with this information, we believe we > cannot. However, we can’t prevent anyone from disassembling the fsbl and > copying the values sent to the blackbox DDR register map." > > and ... there ends my interest in the hifive. A shame. >>> >>> I can't understand what their target audience is? who would buy such a >>> thing? who do they intend to sell these to? I mean the open source >>> people can buy the now very affordable Talos 2L and the cheap-soc people >>> can buy one of the many of ARM boards that litter the marketplace...I >>> don't get it. >> >> I don't think you can compare the HiFive Unleashed with the Talos. They >> really target completely different people and use cases. You could as >> well ask, why produce smart watches, when people can afford the Talos? >> >> Talos is a workstation it doesn't fit anywhere but a workplace where >> somebody else pays the power bill. So you can't even compare it to >> cheap ARM SBCs, HiFive aside. It's a professional product, nothing to >> play with, but something to work with. And it's open. It is marketed >> as open. It is designed to be open. It is based on an open platform. > > I just want to counter this one point. POWER9 is absolutely not power > hungry. I've seen the 8-core chips idle at under 10W, with active loads > maybe in the 40-60W range. We're dogfooding one machine in a typical > office setting, and it dissipates nearly no heat -- it's using less > power than the older Xeon it replaced. Hmmm, yeah, just twist my words as you wish. I never said that it is power hungry compared to other workstation systems. I did not even state that it is power hungry at all. All I said is that it needs power and somebody has to pay for that too. Now you show off with random numbers that make things really weird. 10W for what? per chip? or per core? Whatever it is, I hope your office has air conditioning. And than that "it's using less power than the older Xeon", omg really? you're system is better than shit? Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/24/2018 03:43 PM, Nico Huber wrote: > On 24.06.2018 21:37, taii...@gmx.com wrote: >> On 06/24/2018 02:59 PM, ron minnich wrote: >>> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >>> wrote: >>> "While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map." >>> >>> and ... there ends my interest in the hifive. A shame. >>> >> >> I can't understand what their target audience is? who would buy such a >> thing? who do they intend to sell these to? I mean the open source >> people can buy the now very affordable Talos 2L and the cheap-soc people >> can buy one of the many of ARM boards that litter the marketplace...I >> don't get it. > > I don't think you can compare the HiFive Unleashed with the Talos. They > really target completely different people and use cases. You could as > well ask, why produce smart watches, when people can afford the Talos? > > Talos is a workstation it doesn't fit anywhere but a workplace where > somebody else pays the power bill. So you can't even compare it to > cheap ARM SBCs, HiFive aside. It's a professional product, nothing to > play with, but something to work with. And it's open. It is marketed > as open. It is designed to be open. It is based on an open platform. I just want to counter this one point. POWER9 is absolutely not power hungry. I've seen the 8-core chips idle at under 10W, with active loads maybe in the 40-60W range. We're dogfooding one machine in a typical office setting, and it dissipates nearly no heat -- it's using less power than the older Xeon it replaced. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi, Lets do some speculation that some off the shelf DDR memory controller is used. Maybe it could be same as the RockChip aka Denali High-Speed DDR PHY IP from Cadence? It has also some "interrupt status" bits and such and "bstlen" which sounds same as the few regs named as the documentation. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
I'm still interested in risc-v, just not hifive. In saying I've lost interest, I'm definitely not saying anyone is a bad person. The sifive people are wonderful, personally and professionally, and I wish them the best success. But sifive had to make some decisions to get to what they thought was a commercially viable platform, and those decisions result in a platform that I just don't find interesting. A further disappointment is that in spite of a considerable amount of work on the part of coreboot contributors, as well as no small amount of discussion, directed to getting them to use coreboot ... BBL is still in there. I don't see a reason for the BBL, which has applicability to only one vendor, to continue to exist. I don't see the need for yet another architecture-specific firmware code base. So, I've lost interest in the hifive. I'm looking for a different risc-v implementation to work on. ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 24.06.2018 21:37, taii...@gmx.com wrote: > On 06/24/2018 02:59 PM, ron minnich wrote: >> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer >> wrote: >> >>> >>> >>> "While we’d love to provide you with this information, we believe we >>> cannot. However, we can’t prevent anyone from disassembling the fsbl and >>> copying the values sent to the blackbox DDR register map." >>> >>> >> >> and ... there ends my interest in the hifive. A shame. >> > > I can't understand what their target audience is? who would buy such a > thing? who do they intend to sell these to? I mean the open source > people can buy the now very affordable Talos 2L and the cheap-soc people > can buy one of the many of ARM boards that litter the marketplace...I > don't get it. I don't think you can compare the HiFive Unleashed with the Talos. They really target completely different people and use cases. You could as well ask, why produce smart watches, when people can afford the Talos? Talos is a workstation it doesn't fit anywhere but a workplace where somebody else pays the power bill. So you can't even compare it to cheap ARM SBCs, HiFive aside. It's a professional product, nothing to play with, but something to work with. And it's open. It is marketed as open. It is designed to be open. It is based on an open platform. I guess the HiFive Unleashed targets people who want something new to play with without further investment* on one side; and on the other side those that really want to make their own chips in the future and would benefit from the free (as in free beer) that RISC-V is. That SiFive actually prefers open systems too, didn't prevent them to provide the Unleashed which was never planned to be fully open. The plan was just to get a Linux capable RISC-V SoC as soon as possible, I guess. It's designed to be open-source compatible at the OS level. We know too well what that means. Maybe RISC-V failed (to provide an open platform) and is already borked. For me, all hope died when I heard that Linux will require that SMM like nonsense, although I never thought it would change the game per se. You always need somebody to invest into an open chip. But here is the good news: RISC-V is free (as in free beer). Anybody can salvage all the parts that make sense. If you create an open RISC-V com- petitor, you can use the same compilers, 90% of the Linux support etc. even the better part of the chip design. So investing into RISC-V still isn't all for naught. If somebody wants to try in the future what many people just hoped for (without doing anything), 90% of the work will already be done. Nico * For a Talos 2 I would have to refurnish my living room. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi Ron, Dne 24.6.2018 v 20:59 ron minnich napsal(a): > and ... there ends my interest in the hifive. A shame. Well perhaps because the DDR controller is third party IP, see [1] FAQ or here: > The Freedom U540 SoC is based on the Freedom Unleashed Platform, which has > been open sourced. The Freedom Platform is available at > https://github.com/sifive/freedom and is maintained by SiFive. In the Freedom > Platform, you will find: > > RISC-V Rocket CPU > TileLink, a free and open coherent SoC interconnect > Low-speed Peripherals: SPI, UART, PWM, GPIO, I2C > High-speed Xilinx FPGA Peripheral Wrappers: DDR, PCIe blocks > The Freedom U540 contains many 3rd-party IP: cells, pads, PLL, OTP, DDR, > GbE, ROM, which are not open-sourced And, On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer wrote > "While we’d love to provide you with this information, we believe we > cannot. However, we can’t prevent anyone from disassembling the fsbl and > copying the values sent to the blackbox DDR register map." I think they are even asking to actually make some open version of FSBL Thanks Rudolf [1] https://www.sifive.com/products/hifive-unleashed/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On 06/24/2018 02:59 PM, ron minnich wrote: > On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer > wrote: > >> >> >> "While we’d love to provide you with this information, we believe we >> cannot. However, we can’t prevent anyone from disassembling the fsbl and >> copying the values sent to the blackbox DDR register map." >> >> > > and ... there ends my interest in the hifive. A shame. > I can't understand what their target audience is? who would buy such a thing? who do they intend to sell these to? I mean the open source people can buy the now very affordable Talos 2L and the cheap-soc people can buy one of the many of ARM boards that litter the marketplace...I don't get it. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer wrote: > > > "While we’d love to provide you with this information, we believe we > cannot. However, we can’t prevent anyone from disassembling the fsbl and > copying the values sent to the blackbox DDR register map." > > and ... there ends my interest in the hifive. A shame. ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Fri, Jun 22, 2018 at 01:01:04PM +0200, Jonathan Neuschäfer wrote: [...] > Section 20.3 describes the initialization sequence for the DRAM > controller, but leaves out the values for the register for "memory > timing settings, PAD mode configuration, initialization, and training." > It says: "Please contact SiFive directly to determine the complete > register settings for your application." > > I will ask on the forum. "While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map." (-- https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/3) signature.asc Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Wed, Jun 20, 2018 at 11:03 PM taii...@gmx.com wrote: > > > Whats the deal with SMM? What a shame they thought to add it. > > > It's a huge disappointment. I made some effort a few years ago to try to convince folks this was a bad idea and failed. I'm no longer as optimistic as I was about RISC-V. There seems to be a real push to be "just like x86". ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. I realize there was a lot of hope in the early days that RISC-V implied "openness" but as we can see that is not so. There's blobs in HiFive. Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set. On Fri, Jun 22, 2018 at 6:12 AM Shawn wrote: > On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer > wrote: > > On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: > >> Hi Jonathan, > >> > >> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer > > [...] > >> > With the unfinished coreboot port, I want it to look like this > (although > >> > *a lot* of work has to be done on coreboot first, and I'm currently > not > >> > actively working on that, for a few months): > >> > > >> > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or > >> > MSEL (ROM0) -> coreboot (+bbl?) -> Linux > >> > > >> > ZSBL can be skipped, so you don't need to run closed source ROM code, > at > >> > least as far as the hardware is concerned. > >> > > >> Is ZSBL really can be skipped? I thought it was part of internal ROM > >> inside the chip. > > > > Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM > > (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of > > into the big ROM1, where ZSBL is. > > > > Coreboot doesn't yet support this mode, but the hardware allows it. > > > >> > (And note that this is just the situation on this particular SoC. > Other > >> > SoCs from SiFive or other vendors may boot differently.) > >> > > >> Well, if FSBL is the place where coreboot comes into play, we might > >> only have two options: 1, Reversing the FSBL which is ~9k assembly LOC > >> 2, SiFive make the FSBL open source( I don't see any reason why they > >> don't do it if they intend to build an open eco-system for RISC-V). > > > > A high-level list of tasks that FSBL performs is in the manual[1]: > > > > • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by > > configuring and running off the on-chip PLL > > • Configure DDR PLL, PHY, and controller > > • Set GEM GXL TX PLL to 125 MHz and reset it > > • If there is an external PHY, reset it > > • Download BBL from a partition with GUID type > > 2E54B353-1271-4842-806F-E436D6AF69851 > > • Scan the OTP for the chip serial number > > • Copy the embedded DTB to DDR, filling in FSBL version, memory > > size, and MAC address > > • Enable 15 of the 16 L2 ways (this removes almost all of the L2 > > LIM memory) > > • Jump to DDR memory (0x8000_) > > > > Initializing the PLLs and reading the OTP ROM should be easy enough > > because both are documented in, I think, sufficient detail. > > > > Section 20.3 describes the initialization sequence for the DRAM > > controller, but leaves out the values for the register for "memory > > timing settings, PAD mode configuration, initialization, and training." > > It says: "Please contact SiFive directly to determine the complete > > register settings for your application." > > > > I will ask on the forum. > > > > Assuming that SiFive will tell us the values of the missing > > configuration registers, I don't think we need to reverse-engineer FSBL. > > > That's good to know and it's very helpful. We've been studying how to > make coreboot work on Hifve Unleashed. If the reversing is not > necessary, that'd be save a lot of time especially the decompiler for > RISC-V doesn't exist yet. Thanks for the info. > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer wrote: > On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: >> Hi Jonathan, >> >> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer > [...] >> > With the unfinished coreboot port, I want it to look like this (although >> > *a lot* of work has to be done on coreboot first, and I'm currently not >> > actively working on that, for a few months): >> > >> > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or >> > MSEL (ROM0) -> coreboot (+bbl?) -> Linux >> > >> > ZSBL can be skipped, so you don't need to run closed source ROM code, at >> > least as far as the hardware is concerned. >> > >> Is ZSBL really can be skipped? I thought it was part of internal ROM >> inside the chip. > > Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM > (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of > into the big ROM1, where ZSBL is. > > Coreboot doesn't yet support this mode, but the hardware allows it. > >> > (And note that this is just the situation on this particular SoC. Other >> > SoCs from SiFive or other vendors may boot differently.) >> > >> Well, if FSBL is the place where coreboot comes into play, we might >> only have two options: 1, Reversing the FSBL which is ~9k assembly LOC >> 2, SiFive make the FSBL open source( I don't see any reason why they >> don't do it if they intend to build an open eco-system for RISC-V). > > A high-level list of tasks that FSBL performs is in the manual[1]: > > • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by > configuring and running off the on-chip PLL > • Configure DDR PLL, PHY, and controller > • Set GEM GXL TX PLL to 125 MHz and reset it > • If there is an external PHY, reset it > • Download BBL from a partition with GUID type > 2E54B353-1271-4842-806F-E436D6AF69851 > • Scan the OTP for the chip serial number > • Copy the embedded DTB to DDR, filling in FSBL version, memory > size, and MAC address > • Enable 15 of the 16 L2 ways (this removes almost all of the L2 > LIM memory) > • Jump to DDR memory (0x8000_) > > Initializing the PLLs and reading the OTP ROM should be easy enough > because both are documented in, I think, sufficient detail. > > Section 20.3 describes the initialization sequence for the DRAM > controller, but leaves out the values for the register for "memory > timing settings, PAD mode configuration, initialization, and training." > It says: "Please contact SiFive directly to determine the complete > register settings for your application." > > I will ask on the forum. > > Assuming that SiFive will tell us the values of the missing > configuration registers, I don't think we need to reverse-engineer FSBL. > That's good to know and it's very helpful. We've been studying how to make coreboot work on Hifve Unleashed. If the reversing is not necessary, that'd be save a lot of time especially the decompiler for RISC-V doesn't exist yet. Thanks for the info. -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: > Hi Jonathan, > > On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer [...] > > With the unfinished coreboot port, I want it to look like this (although > > *a lot* of work has to be done on coreboot first, and I'm currently not > > actively working on that, for a few months): > > > > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or > > MSEL (ROM0) -> coreboot (+bbl?) -> Linux > > > > ZSBL can be skipped, so you don't need to run closed source ROM code, at > > least as far as the hardware is concerned. > > > Is ZSBL really can be skipped? I thought it was part of internal ROM > inside the chip. Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of into the big ROM1, where ZSBL is. Coreboot doesn't yet support this mode, but the hardware allows it. > > (And note that this is just the situation on this particular SoC. Other > > SoCs from SiFive or other vendors may boot differently.) > > > Well, if FSBL is the place where coreboot comes into play, we might > only have two options: 1, Reversing the FSBL which is ~9k assembly LOC > 2, SiFive make the FSBL open source( I don't see any reason why they > don't do it if they intend to build an open eco-system for RISC-V). A high-level list of tasks that FSBL performs is in the manual[1]: • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by configuring and running off the on-chip PLL • Configure DDR PLL, PHY, and controller • Set GEM GXL TX PLL to 125 MHz and reset it • If there is an external PHY, reset it • Download BBL from a partition with GUID type 2E54B353-1271-4842-806F-E436D6AF69851 • Scan the OTP for the chip serial number • Copy the embedded DTB to DDR, filling in FSBL version, memory size, and MAC address • Enable 15 of the 16 L2 ways (this removes almost all of the L2 LIM memory) • Jump to DDR memory (0x8000_) Initializing the PLLs and reading the OTP ROM should be easy enough because both are documented in, I think, sufficient detail. Section 20.3 describes the initialization sequence for the DRAM controller, but leaves out the values for the register for "memory timing settings, PAD mode configuration, initialization, and training." It says: "Please contact SiFive directly to determine the complete register settings for your application." I will ask on the forum. Assuming that SiFive will tell us the values of the missing configuration registers, I don't think we need to reverse-engineer FSBL. Greetings, Jonathan Neuschäfer [1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/ signature.asc Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hi Jonathan, On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer wrote: > Hello Taiidan and Timothy, > > On Thu, Jun 21, 2018 at 01:14:05AM -0500, Timothy Pearson wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 06/20/2018 09:13 PM, taii...@gmx.com wrote: >> > https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot >> > >> > The board costs almost as much as a significantly faster and with much >> > more features (IOMMU!) TALOS 2 Lite so I think it is not really worth >> > buying right now for someone like me but I am still very curious about it. >> > >> > - Unlike the usual crappy SOC products like this there is an available >> > sexy expansion board which contains not one but two PCI-e slots and >> > various other expansion options including SATA...which all really should >> > have came standard. But unfortunately once you buy all the extras that >> > make it usable you could have bought a very nice T2 setup so this is >> > only for the die-hard hero developers and early adopters. (But I wish I >> > had the cash for both!) > > Fully agreed. It's a devboard and the purpose is to help spread RISC-V, > whereas the Talos 2 (Lite) is a usable machine with all the bells and > whistles that you'd expect. > > Note that the expansion board[1] is designed around a Microsemi FPGA, > however that influences your freedom rating. > > (It should be possible though to implement an expansion board with a > free bitstream: SiFive has published an implementation of ChipLink[2], > and the FMC connector[3] is an industry standard.) > >> > >> > >> > My questions: >> > >> > Is it possible to do normal stuff like browse the internet and watch a >> > film via video acceleration if you pop in a decent graphics card? > > Yes. The FOSDEM presentation was held on a HiFive Unleashed with an > external graphics card. > >> > Are there absolutely no binary blobs? Not even for the NIC? > > It's a Cadence GEMGXL (aka. MACB) integrated into the SoC, plus an > external PHY. No idea. > >> > It is difficult to find NIC ASIC's that don't have blobs and with RISCV's >> > unfortunate lack of an IOMMU this is a very big security issue for >> > RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from >> > doing anything evil and various people are working on a libre >> > replacement which will benefit the entire libre community and anyone >> > that likes cheap+good nics. > > I'm sure IOMMUs will come to RISC-V as well. > >> > >> > Whats the deal with SMM? What a shame they thought to add it. > > Yes, unfortunately runtime-resident code in a mode similar to SMM is a > platform requirement, and Linux relies on it. (The interface that Linux > expects is called the SBI / Supervisor Binary Interface.) > >> > >> > >> > I really hope this succeeds and that they eventually add an IOMMU. >> > >> >> Their bootloader is a blob in ROM, for what it's worth. They also will >> not release source for it [1]. I haven't looked further since that >> alone is a dealbreaker for an "open" / auditable chip. > > Let me add a bit of detail here: > > The original boot chain on the SiFive FU540 looks like this: > > MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux > > Where the individual pieces mean this: > > MSEL: The "Mode select" ROM, consisting of a register that represents > the state of four pins on the chip, and six instructions, which > jump to the selected boot device or ZSBL. > Fully documented (with an instruction listing) in the manual. > > ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM, > which parses a GPT header on SPI flash or an SD card and loads the > next stage. > Short, high-level documentation in the manual; I haven't seen the > source code. > > FSBL: The "First stage bootloader", where interesting things like RAM > init happen. > High-level documentation in the manual; I haven't seen the source > code. > > BBL: The "Berkeley bootloader". Its most important role, as far as I > understand it, is to implement the SBI. > The source code is public. > > See also chapter 6 (Boot process) of the FU540-C000 Manual[4]. > > With the unfinished coreboot port, I want it to look like this (although > *a lot* of work has to be done on coreboot first, and I'm currently not > actively working on that, for a few months): > > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or > MSEL (ROM0) -> coreboot (+bbl?) -> Linux > > ZSBL can be skipped, so you don't need to run closed source ROM code, at > least as far as the hardware is concerned. > Is ZSBL really can be skipped? I thought it was part of internal ROM inside the chip. > (And note that this is just the situation on this particular SoC. Other > SoCs from SiFive or other vendors may boot differently.) > Well, if FSBL is the place where coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
Hello Taiidan and Timothy, On Thu, Jun 21, 2018 at 01:14:05AM -0500, Timothy Pearson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/20/2018 09:13 PM, taii...@gmx.com wrote: > > https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot > > > > The board costs almost as much as a significantly faster and with much > > more features (IOMMU!) TALOS 2 Lite so I think it is not really worth > > buying right now for someone like me but I am still very curious about it. > > > > - Unlike the usual crappy SOC products like this there is an available > > sexy expansion board which contains not one but two PCI-e slots and > > various other expansion options including SATA...which all really should > > have came standard. But unfortunately once you buy all the extras that > > make it usable you could have bought a very nice T2 setup so this is > > only for the die-hard hero developers and early adopters. (But I wish I > > had the cash for both!) Fully agreed. It's a devboard and the purpose is to help spread RISC-V, whereas the Talos 2 (Lite) is a usable machine with all the bells and whistles that you'd expect. Note that the expansion board[1] is designed around a Microsemi FPGA, however that influences your freedom rating. (It should be possible though to implement an expansion board with a free bitstream: SiFive has published an implementation of ChipLink[2], and the FMC connector[3] is an industry standard.) > > > > > > My questions: > > > > Is it possible to do normal stuff like browse the internet and watch a > > film via video acceleration if you pop in a decent graphics card? Yes. The FOSDEM presentation was held on a HiFive Unleashed with an external graphics card. > > Are there absolutely no binary blobs? Not even for the NIC? It's a Cadence GEMGXL (aka. MACB) integrated into the SoC, plus an external PHY. No idea. > > It is difficult to find NIC ASIC's that don't have blobs and with RISCV's > > unfortunate lack of an IOMMU this is a very big security issue for > > RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from > > doing anything evil and various people are working on a libre > > replacement which will benefit the entire libre community and anyone > > that likes cheap+good nics. I'm sure IOMMUs will come to RISC-V as well. > > > > Whats the deal with SMM? What a shame they thought to add it. Yes, unfortunately runtime-resident code in a mode similar to SMM is a platform requirement, and Linux relies on it. (The interface that Linux expects is called the SBI / Supervisor Binary Interface.) > > > > > > I really hope this succeeds and that they eventually add an IOMMU. > > > > Their bootloader is a blob in ROM, for what it's worth. They also will > not release source for it [1]. I haven't looked further since that > alone is a dealbreaker for an "open" / auditable chip. Let me add a bit of detail here: The original boot chain on the SiFive FU540 looks like this: MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux Where the individual pieces mean this: MSEL: The "Mode select" ROM, consisting of a register that represents the state of four pins on the chip, and six instructions, which jump to the selected boot device or ZSBL. Fully documented (with an instruction listing) in the manual. ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM, which parses a GPT header on SPI flash or an SD card and loads the next stage. Short, high-level documentation in the manual; I haven't seen the source code. FSBL: The "First stage bootloader", where interesting things like RAM init happen. High-level documentation in the manual; I haven't seen the source code. BBL: The "Berkeley bootloader". Its most important role, as far as I understand it, is to implement the SBI. The source code is public. See also chapter 6 (Boot process) of the FU540-C000 Manual[4]. With the unfinished coreboot port, I want it to look like this (although *a lot* of work has to be done on coreboot first, and I'm currently not actively working on that, for a few months): MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or MSEL (ROM0) -> coreboot (+bbl?) -> Linux ZSBL can be skipped, so you don't need to run closed source ROM code, at least as far as the hardware is concerned. (And note that this is just the situation on this particular SoC. Other SoCs from SiFive or other vendors may boot differently.) Greetings, Jonathan Neuschäfer [1]: https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-board [2]: https://github.com/sifive/sifive-blocks/tree/c340d7ade16a9bea307685c54a13d830fa90bc3b/src/main/scala/devices/chiplink [3]: https://en.wikipedia.org/wiki/FPGA_Mezzanine_Card [4]:
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2018 01:14 AM, Timothy Pearson wrote: > On 06/20/2018 09:13 PM, taii...@gmx.com wrote: >> https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot > >> The board costs almost as much as a significantly faster and with much >> more features (IOMMU!) TALOS 2 Lite so I think it is not really worth >> buying right now for someone like me but I am still very curious about it. > >> - Unlike the usual crappy SOC products like this there is an available >> sexy expansion board which contains not one but two PCI-e slots and >> various other expansion options including SATA...which all really should >> have came standard. But unfortunately once you buy all the extras that >> make it usable you could have bought a very nice T2 setup so this is >> only for the die-hard hero developers and early adopters. (But I wish I >> had the cash for both!) > > >> My questions: > >> Is it possible to do normal stuff like browse the internet and watch a >> film via video acceleration if you pop in a decent graphics card? > >> Are there absolutely no binary blobs? Not even for the NIC? It is >> difficult to find NIC ASIC's that don't have blobs and with RISCV's >> unfortunate lack of an IOMMU this is a very big security issue for >> RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from >> doing anything evil and various people are working on a libre >> replacement which will benefit the entire libre community and anyone >> that likes cheap+good nics. > >> Whats the deal with SMM? What a shame they thought to add it. > > >> I really hope this succeeds and that they eventually add an IOMMU. > > > Their bootloader is a blob in ROM, for what it's worth. They also will > not release source for it [1]. I haven't looked further since that > alone is a dealbreaker for an "open" / auditable chip. > > [1] https://www.bunniestudios.com/blog/?p=5127 > Correction: it's the pre-boot loader that's the problem. POWER neatly sidesteps that since the chip doesn't use any pre-reset code per se, and in fact goes through a lengthy process to reset all the latches as part of the open source boot code (see scan rings, etc.). I'd expect more, a *lot* more, from RISC-V to compensate for its lack of performance and other features. Seeing the only fabbed general purpose chip (AFAIK) be more closed than a closed-ISA competitor is not encouraging at this stage. Just my personal $0.02 here, not speaking for Raptor overall :) - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbK0NCAAoJEK+E3vEXDOFbUYgH/3w6mmD1BORMy7DB4vzjixFb 8LcJdAxFu6vsWqbl9Va2wvO11k8yqz9LOlk3c+YcDo3/uozlHyOGQrjKciSUFjtB vsu4p0v40bpHYOxMoictYbxLMJ7fFC1XNKjwEFclLpJ5y2YfuHx7p+lZ2KVrJca2 HNxIWjinYSuAcX6FFQCCeGPkHPcnFKfQz9vLQqAh8zZOOYIaGFT4NDTXlDu1W34/ +I5wzG1r7/o+uSQqLYE5zJQlru4nCbsU8H4SBEZvw+hNGTzdHrpVB6jrvj+z5QeI yFxUjOo6YvhVwn7gN9CRUJmazB5hJonCSxnDdsnO5i7631E7UXnYOjIozqoHi9U= =jstT -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/20/2018 09:13 PM, taii...@gmx.com wrote: > https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot > > The board costs almost as much as a significantly faster and with much > more features (IOMMU!) TALOS 2 Lite so I think it is not really worth > buying right now for someone like me but I am still very curious about it. > > - Unlike the usual crappy SOC products like this there is an available > sexy expansion board which contains not one but two PCI-e slots and > various other expansion options including SATA...which all really should > have came standard. But unfortunately once you buy all the extras that > make it usable you could have bought a very nice T2 setup so this is > only for the die-hard hero developers and early adopters. (But I wish I > had the cash for both!) > > > My questions: > > Is it possible to do normal stuff like browse the internet and watch a > film via video acceleration if you pop in a decent graphics card? > > Are there absolutely no binary blobs? Not even for the NIC? It is > difficult to find NIC ASIC's that don't have blobs and with RISCV's > unfortunate lack of an IOMMU this is a very big security issue for > RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from > doing anything evil and various people are working on a libre > replacement which will benefit the entire libre community and anyone > that likes cheap+good nics. > > Whats the deal with SMM? What a shame they thought to add it. > > > I really hope this succeeds and that they eventually add an IOMMU. > Their bootloader is a blob in ROM, for what it's worth. They also will not release source for it [1]. I haven't looked further since that alone is a dealbreaker for an "open" / auditable chip. [1] https://www.bunniestudios.com/blog/?p=5127 - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbK0IrAAoJEK+E3vEXDOFbEgsH/Rtp94joxCtDEbDXEkO5fzXv GdnPoiDZksSDp2BmjFrcTtA3wb5f44WIiM+IanQ+HO1xnQDnEcCOoiAFE1eJ/j+1 JdUpLUy77u6D0j8gKcmuVct8VW+99o9F7RIHXpzkyRAXKf6WycHGxElsTSBpBWL3 UvAh3B0fknlENGJWKGVNfUPyUwgCzlJKN5fJd6izukcA9lg/x+6HRRmrQZFXM2l3 fe4n0p0j/20N8ex+142AAR4FuOdrYRCkhN7FIm/Aq3gwp3FiHJOhdytmMyDmkfL/ KxeZhDvxG4Oubi9kqa+yDP08HOJYtZ690usNXQCwZkfsvGmpsYts/WZvWmesGFI= =PhY+ -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot The board costs almost as much as a significantly faster and with much more features (IOMMU!) TALOS 2 Lite so I think it is not really worth buying right now for someone like me but I am still very curious about it. - Unlike the usual crappy SOC products like this there is an available sexy expansion board which contains not one but two PCI-e slots and various other expansion options including SATA...which all really should have came standard. But unfortunately once you buy all the extras that make it usable you could have bought a very nice T2 setup so this is only for the die-hard hero developers and early adopters. (But I wish I had the cash for both!) My questions: Is it possible to do normal stuff like browse the internet and watch a film via video acceleration if you pop in a decent graphics card? Are there absolutely no binary blobs? Not even for the NIC? It is difficult to find NIC ASIC's that don't have blobs and with RISCV's unfortunate lack of an IOMMU this is a very big security issue for RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from doing anything evil and various people are working on a libre replacement which will benefit the entire libre community and anyone that likes cheap+good nics. Whats the deal with SMM? What a shame they thought to add it. I really hope this succeeds and that they eventually add an IOMMU. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
