[coreboot] Can't sleep/power down after flashing coreboor
Hello, I am running Coreboor on my X230 which has Windows 10 and Qubes OS installed. After some issues I was able to run both OSes encrypted and all devices (WiFi/WWAN/...) are working under coreboot. (in Qubes and Windows). Today I found out that I am unable to shutdown or put my laptop to sleep in under Qubes/Linux. It was working before and it is also working under windows (currently). Do you have any idea where to look for a root cause why Linux can't be shutdown. If I try it, the screen will go blank but the system stays up and running. I tried closing the lid and also a shutdown -h now. Regards [799] -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What happened to the Option ROM options?
On 06/21/2018 04:51 AM, Nico Huber wrote: > On 21.06.2018 03:47, taii...@gmx.com wrote: >> Ah oops overlooked this. >> https://review.coreboot.org/#/c/coreboot/+/2531/ >> >> Paging ron minnich! It seems at the end of the comments various people >> note the mistake however it never got fixed. > > There is no mistake here. The change was only a little ahead of its > time. There was limited support for non-VGA option ROMs but that was > not working well and SeaBIOS has better support for it. Since [1], > coreboot only executes the option ROMs of VGA devices. The later > changes you noticed only fix the Kconfig options to reflect that. Ah thanks for the info. But what about initializing non-integrated PCI-e graphics devices on a board that has native graphics init (where the option doesn't appear) and being able to choose the various YABEL options? > > So if you need non-VGA option ROMs, consider using SeaBIOS. > >> If this is a mistake I will require someone else to fix it as I am not >> allowed to contribute on gerrit. > > You are free to contribute. And if you had listened in the last discus- > sion about our sign-off procedure, you would know that even you can do > so without sacrifice. Could you please provide a link for that? I always read all the replies but I hadn't noticed anything about being able to sidestep the requirement to use your "real" name. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Thinkpad SD card controller DMA
Sounds like disabling the PCIe port of the device is the safest solution. Will switching the value in the devicetree be enough or is that too uncertain? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Equus "WHITEBOX OPEN" servers ship with Coreboot/LinuxBoot
i'm going to be talking to them. On Thu, Jun 21, 2018 at 11:36 AM David Hendricks wrote: > I'm calling shenanigans on this. Their server datasheets pretty clearly > specify an IBV-provided firmware solution, definitely NOT coreboot or > LinuxBoot and definitely NOT open. I did hear thru the grapevine that > they've been in contact with at least one OpenBMC developer, at least. > > So basically this is a lot of misleading marketing BS AFAICT (though I'd > like to be proven wrong). > > On Thu, Jun 21, 2018 at 4:56 AM, Alberto Bursi > wrote: > >> There was an announcement [1] about a new line of servers called >> WHITEBOX OPEN (yes, all caps) >> >> which appears to be about servers with Coreboot or Linuxboot and OpenBMC. >> >> Has anyone any experience with this company? >> >> >> -Alberto >> >> 1. https://www.prweb.com/releases/2018/06/prweb15571110.htm >> >> -- >> 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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Equus "WHITEBOX OPEN" servers ship with Coreboot/LinuxBoot
I'm calling shenanigans on this. Their server datasheets pretty clearly specify an IBV-provided firmware solution, definitely NOT coreboot or LinuxBoot and definitely NOT open. I did hear thru the grapevine that they've been in contact with at least one OpenBMC developer, at least. So basically this is a lot of misleading marketing BS AFAICT (though I'd like to be proven wrong). On Thu, Jun 21, 2018 at 4:56 AM, Alberto Bursi wrote: > There was an announcement [1] about a new line of servers called > WHITEBOX OPEN (yes, all caps) > > which appears to be about servers with Coreboot or Linuxboot and OpenBMC. > > Has anyone any experience with this company? > > > -Alberto > > 1. https://www.prweb.com/releases/2018/06/prweb15571110.htm > > -- > 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] Thinkpad SD card controller DMA
On 21.06.2018 13:20, Jose Trujillo via coreboot wrote: > If you don't enable a device in devicetree the initialization routine will > not be executed. Interpretation of the devicetree on/off values depends on the chipset code. And even if the chipset code disables (or doesn't enable) some- thing, this might just mean that the device is not visible any more. Beside the IOMMU protection, there are two other options to prevent a PCI device from DMA: 1. The Bus-Master bit in the device' PCI-Command register. Though, enforcement of the bit is implementation specific. 2. Disabling the PCIe port of the chipset / bridge. If this is possible is also implementation specific. > To test just insert a SD card and use DMESG or other command to see if device > ID is found, also in device manager in Windows. Alas, a non-functioning device driver is no proof that DMA can't happen. If you want to be sure, find research (for exactly your platform) that confirms that a given method prevents DMA; or, get a programmable PCIe device and test it yourself. There are no shortcuts. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Equus "WHITEBOX OPEN" servers ship with Coreboot/LinuxBoot
There was an announcement [1] about a new line of servers called WHITEBOX OPEN (yes, all caps) which appears to be about servers with Coreboot or Linuxboot and OpenBMC. Has anyone any experience with this company? -Alberto 1. https://www.prweb.com/releases/2018/06/prweb15571110.htm -- 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
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] Thinkpad SD card controller DMA
If you don't enable a device in devicetree the initialization routine will not be executed. To test just insert a SD card and use DMESG or other command to see if device ID is found, also in device manager in Windows. JT. ‐‐‐ Original Message ‐‐‐ On June 21, 2018 2:06 PM, Thomasheidler via coreboot wrote: > That's what I'm thinking about, but I am not able to test a build with it > removed from the devicetree to see if that does the trick, so I was wondering > if anybody knows. > - > > 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] Thinkpad SD card controller DMA
That's what I'm thinking about, but I am not able to test a build with it removed from the devicetree to see if that does the trick, so I was wondering if anybody knows. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Thinkpad SD card controller DMA
Hello Thomas, It is not enough just to disable it from the devicetree ? JT. ‐‐‐ Original Message ‐‐‐ On June 21, 2018 1:43 PM, Thomasheidler via coreboot wrote: > Thanks for your response and suggestions. > > Luckily I don’t need the SD card reader and would rather completely disable > it to protect against any DMA attack before the kernel initializes IOMMU. The > problem is that I don’t know how to prevent the controller from initializing > at all, short of actually desoldering the chip from the mainboard, which is > risky. > > Regarding the EC, are you aware of any working libre replacement for the EC > on any Lenovo Thinkpad? > > > - > > 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] Thinkpad SD card controller DMA
Thanks for your response and suggestions. Luckily I don’t need the SD card reader and would rather completely disable it to protect against any DMA attack before the kernel initializes IOMMU. The problem is that I don’t know how to prevent the controller from initializing at all, short of actually desoldering the chip from the mainboard, which is risky. Regarding the EC, are you aware of any working libre replacement for the EC on any Lenovo Thinkpad? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What happened to the Option ROM options?
On 21.06.2018 03:47, taii...@gmx.com wrote: > Ah oops overlooked this. > https://review.coreboot.org/#/c/coreboot/+/2531/ > > Paging ron minnich! It seems at the end of the comments various people > note the mistake however it never got fixed. There is no mistake here. The change was only a little ahead of its time. There was limited support for non-VGA option ROMs but that was not working well and SeaBIOS has better support for it. Since [1], coreboot only executes the option ROMs of VGA devices. The later changes you noticed only fix the Kconfig options to reflect that. So if you need non-VGA option ROMs, consider using SeaBIOS. > If this is a mistake I will require someone else to fix it as I am not > allowed to contribute on gerrit. You are free to contribute. And if you had listened in the last discus- sion about our sign-off procedure, you would know that even you can do so without sacrifice. Nico [1] https://review.coreboot.org/#/c/coreboot/+/4545/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
On 21.06.2018 02:34, Zvi Vered wrote: > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set> > Should vendor supply code for this ? or any other information ? PCIe configuration is SoC specific and should be done by FSP. However, I can't find any PCIe specific settings for the BayTrail FSP. As this is one of the earlier FSP releases, it is not unlikely that it does not expose all the option Intel's reference code provides. I'll add the maintainers of the BayTrail FSP hook-up in CC. Maybe they can tell us more about it. > How can I write it from scratch ? Can Intel provide information on how to > implement this initialization ? AFAIK, Intel does not document PCIe initialization and encourages every- one to use their reference code (which is compiled into FSP). It's a shame that they don't allow open-source implementations because we can't make any alterations to FSP once Intel thinks it's finished (which is almost always too early, IMHO). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
Hello Zvika, Look for the list of Linux commands to dump many of the information from your original BIOS running, maybe there you will find this information. Also, some configuration can be seen from your original BIOS running Intel FIT for Baytrail in Windows. About configuring those settings in coreboot look for other examples in the coreboot tree about configuring PCI devices in devicetree.cb and other places. I Am new to coreboot too and please correct me if I Am wrong. Good Luck! J. Trujillo ‐‐‐ Original Message ‐‐‐ On June 21, 2018 3:34 AM, Zvi Vered wrote: > Hello, > > Thank you very much for the detailed reply. > Vendor's BIOS contains few peripherals initialization. > For example: PCIe enumeration, SATA controller, USB etc. > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. > Should vendor supply code for this ? or any other information ? > How can I write it from scratch ? Can Intel provide information on how to > implement this initialization ? > > Thank you, > Zvika > > On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot > wrote: > >> Hello Zvika: >> 1.- Usually it is not necessary to change the CBFS size unless the compiler >> complain of lack of space. >> 2.- You should not worry about this setting to make your system to work. >> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO >> because it will enable SOC internal COM1, instead (if your plan is to use >> FSP) enable FSP and add a VGA bios bin manually (The use of FSP is >> optional but I never tried without FSP). >> 4.- You need to add them yourself, there are examples to follow in this mail >> list. >> Good luck! >> J.Trujillo >> >> ‐‐‐ Original Message ‐‐‐ >> On June 18, 2018 6:24 AM, Zvi Vered wrote: >> >>> Hello, >>> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make >>> distclean I chose: >>> Mainboard vendor: Intel >>> Mainboard model: Bayley Bay FSP-based CRB >>> 1. The size of CBFS is: 0x20. Is it a fix size or should I change it >>> according to my board (which is also bay trail) ? >>> 2. According to "dmidecode" I ran on my target, "Address: 0xE" >>> Should I set this address in coreboot configuration ? How ? >>> >>> 3. In this board default configuration, "Configure defaults for the Intel >>> FSP package" is not selected. Is it possible that this board does not use >>> Intel FSP at all ? >>> Under "Generic Drivers", "Use Intel firmware Support Package' is also not >>> selected. >>> >>> 4. Under "chipset", there is no option to set "Super I/O". Can you please >>> tell why ? >>> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of >>> coreboot.rom is also 4MB. >>> >>> Thank you in advance, >>> Zvika >> >> -- >> 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] Bayley Bay FSP-based CRB
Hello Zvika, On 18.06.2018 05:24, Zvi Vered wrote: > 1. The size of CBFS is: 0x20. Is it a fix size or should I change it > according to my board (which is also bay trail) ? on Intel platforms, the SPI flash is shared with other chipset compo- nents. The CBFS_SIZE should be at most the size of the "BIOS" region of the flash. > 3. In this board default configuration, "Configure defaults for the Intel > FSP package" is not selected. Is it possible that this board does not use > Intel FSP at all ? > > Under "Generic Drivers", "Use Intel firmware Support Package' is also not > selected. > FSP is mandatory for a bootable image. It is not enabled by default because Intel does not (always) publish the matching binaries, but our build tests require the defaults to build. This leaves us with unfor- tunate default settings for all Intel FSP platforms that will never boot. If you think that is a bad idea (I do) please let Intel know that you are interested in working defaults and that it requires them to publish all the binaries that are integrated into coreboot. > 4. Under "chipset", there is no option to set "Super I/O". Can you please > tell why ? Our config options do not allow board specific changes. For such settings, each board has it's own directory and Kconfig file (src/mainboard///Kconfig). > > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of > coreboot.rom is also 4MB. That is correct, but keep in mind that the flash is shared. The resulting coreboot.rom might not contain everything that is required to boot. So it is best advised to only flash the "BIOS" region of the coreboot.rom. Hope that helps, 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
-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
Re: [coreboot] What happened to the Option ROM options?
Ah oops overlooked this. https://review.coreboot.org/#/c/coreboot/+/2531/ Paging ron minnich! It seems at the end of the comments various people note the mistake however it never got fixed. If this is a mistake I will require someone else to fix it as I am not allowed to contribute on gerrit. -- 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
[coreboot] What happened to the Option ROM options?
Using KGPE-D16 with master. The choices for them have been messed around with in kconfig sometime ago: In /src/device/kconfig ON_DEVICE_ROM_LOAD has for some reason been changed to require VGA_ROM_RUN which makes no sense to me (maybe someone could need option ROM's without VGA option ROM's?) and VGA_ROM_RUN is not available on boards with native (coreboot) init irregardless so people don't see it even if they require Option ROM's for whatever reason without SeaBIOS. Does anyone know where the changelog for this is? and maybe can explain what the reasoning is behind it? (if it is not a mistake) Before...I believe last in v4.5 they were shown all the time. I attempted to find the change in gerrit etc but I was unable to locate it. Thanks! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
