Re: [coreboot] About Paging, Realmode and what is going on

> Linux, for a long time, did not need no steenkin' BIOS (you can find that quote if you look back far enough). *But those days are gone.* This is the reason why INTEL has no chance to win IoT race with ARM (just in few special use cases). With all these compatibilities, and test modes, INTEL is

Re: [coreboot] Moving the command line for Linux kernel payloads

Trammell Hudson wrote: > Is there a current or historical reason for the ordering? My best guess: They are stored in CBFS in the order that they appear in RAM at run time. If so, no problem changing the order in CBFS. //Peter -- coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

On Thu, Sep 7, 2017 at 1:40 PM, Nico Huber wrote: > Hello Alberto, > > On 09/06/2017 09:30 PM, Alberto Bursi wrote: >> I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based >> "industrial" mini-itx motherboard) on ebay and since it is supported by >> Coreboot I was

Re: [coreboot] About Paging, Realmode and what is going on

Julius Werner wrote: > while the program was running it mostly interacted with the BIOS directly. Not in general - that is/was highly dependent on the program. BIOS interrupt services offer a hardware abstraction, but they come at a (high! interrupts are very expensive!) cost. For anything

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

Hello Alberto, On 09/06/2017 09:30 PM, Alberto Bursi wrote: > I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based > "industrial" mini-itx motherboard) on ebay and since it is supported by > Coreboot I was considering about purchasing it. > > The APU onboard supports ECC ram (ECC

Re: [coreboot] Moving the command line for Linux kernel payloads

2017-09-07 0:09 GMT+02:00 Trammell Hudson : > Is there a current or historical reason for the ordering? The reason for this order is that there had to be _some_ order. So go ahead and push the change for review, it looks reasonable. Thanks, Patrick -- Google Germany GmbH,

Re: [coreboot] [kernel-hardening] ME and PSP

ron minnich wrote: > I don't think we can assume that an open, unlicensed instruction set > guarantees open, unlicensed, blob-free CPUs and platforms. This is of course absolutely accurate. But a freely licensed ISA and implementation(s) thereof are *one step* in the right direction, and a

Re: [coreboot] About Paging, Realmode and what is going on

On Thu, Sep 7, 2017 at 1:43 AM Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > > Please, could you try to do this with INTEL ATOM or CORE in this time for > this price? ;-) > > > This is a very interesting point about time to market, which is everything nowadays. I regret that ARM

Re: [coreboot] [kernel-hardening] ME and PSP

On Thu, Sep 7, 2017 at 1:07 AM Shawn wrote: > > RISC-V doesn't have NDA issues like x86 which the firmware freedom > will get benefit of it. > Speaking as someone who has been working on and off with riscv for almost four years, and who has ported coreboot several times and

Re: [coreboot] Moving the command line for Linux kernel payloads

It's a great idea. On Thu, Sep 7, 2017 at 6:29 AM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote: > 2017-09-07 0:09 GMT+02:00 Trammell Hudson : > > Is there a current or historical reason for the ordering? > The reason for this order is that there had to be _some_

Re: [coreboot] [kernel-hardening] ME and PSP

On Thu, Sep 7, 2017 at 11:03 AM Timothy Pearson < tpear...@raptorengineering.com> wrote: > could anyone shed some light on these decision making > processes? An open ISA and core design does not guarantee open silicon, > and in fact one could argue that it will mean any performance >

Re: [coreboot] [kernel-hardening] ME and PSP

Am 07.09.2017 20:03 schrieb "Timothy Pearson" < tpear...@raptorengineering.com>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/2017 10:11 AM, Peter Stuge wrote: > ron minnich wrote: >> I don't think we can assume that an open, unlicensed instruction set >> guarantees open, unlicensed,

Re: [coreboot] [kernel-hardening] ME and PSP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/2017 01:24 PM, ron minnich wrote: > > > On Thu, Sep 7, 2017 at 11:03 AM Timothy Pearson > > > wrote: > > could anyone shed some light on these decision making >

Re: [coreboot] [kernel-hardening] ME and PSP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/2017 10:11 AM, Peter Stuge wrote: > ron minnich wrote: >> I don't think we can assume that an open, unlicensed instruction set >> guarantees open, unlicensed, blob-free CPUs and platforms. > > This is of course absolutely accurate. > > But

[coreboot] INT 13, real mode, block write commands and coreboot

Dear Vincent, dear guys thanks very much for your reply. >I don't own a raspi, just another SBC like it. I think that the embedded solution is the best. However, Raspberry hasn't SATA ports, only USBs. Please, can you suggest me a SBC like Raspy that also allows SATA connections (eSATA) ?

Re: [coreboot] INT 13, real mode, block write commands and coreboot

Hello, On Thu, Sep 7, 2017 at 8:02 PM, ingegneriafore...@alice.it wrote: > However, Raspberry hasn't SATA ports, only USBs. You can use usb/sata dongle or enclosure if you won't mind the slight (if usb3 + uasp) performance hit. USB2 won't be practical, due to very

Re: [coreboot] Open systems: RISC-V and POWER8/9 [was: ME and PSP]

Timothy Pearson wrote: > > The fabulous thing about RISC-V is what makes ARM successful; there > > can and will be multiple different silicon vendors, offering products > > with many different features and tradeoffs. > > > > Some can be top performance but proprietary. > > Some can be

Re: [coreboot] INT 13, real mode, block write commands and coreboot

AFAIK the more higher performance beagleboards such as the X15 have native pci-e devices for sata, esata, ethernet etc. I would suggest a more free device such as a BeagleBoard, the RPI foundation only likes open source when it is convenient with them (side question - how come so many laymen

[coreboot] KGPE-D16 PCI passthrough

Hi, I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed video card and the LSI 1394a controller. I try to pass them all to a VM, but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10. Does

Re: [coreboot] INT 13, real mode, block write commands and coreboot

On Thu, Sep 7, 2017 at 7:44 PM taii...@gmx.com wrote: > (side > question - how come so many laymen think it is an open source hardware?) > > marketing, I think. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 PCI passthrough

On 09/07/2017 11:21 PM, Iru Cai wrote: Hi, I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed video card and the LSI 1394a controller. I try to pass them all to a VM, but then kernel crashes. I tried

Re: [coreboot] [kernel-hardening] ME and PSP

Am Donnerstag, den 07.09.2017, 04:30 + schrieb ron minnich: > > very closed system with RISCV very easily. RISCV doesn't magically > take > away ME- and PSP-like problems. But it will magically take away microcode and maybe compatibility-modes – what will already be a progress. Both in

Re: [coreboot] [kernel-hardening] ME and PSP

Hi Ron, On Thu, Sep 7, 2017 at 12:30 PM, ron minnich wrote: > > > On Wed, Sep 6, 2017 at 8:07 PM Shawn wrote: >> >> >> IMOHO, RISC-V will be the long-term solution in the future;-) >> > > people need to stop saying that. It's not that simple. And, sadly,

[coreboot] R: Re: INT 13, real mode, block write commands and coreboot

Dear Vincent, dear guys thanks very much for your reply. >I don't own a raspi, just another SBC like it. I think that the embedded solution is the best. However, Raspberry hasn't SATA ports, only USBs. Please, can you suggest me a SBC like Raspy that also allows SATA connections (eSATA) ?