coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] Early debugging
by Gergely Kiss 18 Dec '17

18 Dec '17

Hi, thanks for all the advice, so far! I've made a lot of progress here: after configuring all the low-level registers (drive strength control, oscillator clock control, SIO GPIO/EC registers) as per the vendor BIOS, coreboot finally started to boot up! Here's what's working so far: * Serial console * GPIO & EC configuration * Loading the VGA BIOS blob through SeaBIOS - I have text mode console output through the D-SUB interface (other outputs need to be tested) * Low level CPU and RAM initialization works perfectly. I have run one pass of memtest for an hour, it could read the SPD chip and the test completed without errors * Coreboot boots up somewhat fine. It shows some resource allocation issues but still, the boot process reaches to payload execution phase. SeaBIOS, nvramcui & memtest payloads can be booted without any issues. * Starting a bootloader through SeaBIOS works - tested with ISOLINUX & Windows bootloader, so far Some problems I'm facing: * USB keyboard support is quite unstable with SeaBIOS, most of the time the keyboard is not detected (it works about once every five-six boots), regardless of what other USB devices are connected to the board * The PCIe Bridge interface of the northbridge (@00:02.1) cannot be configured for some reason. I can see Coreboot correctly identifies and configures the device as a bridge but sending cmd 07 (not sure what that means) to the device completely halts the system. Disabling the device in devicetree makes it possible to avoid the lockup but I think I should not let the device unconfigured. * Booting up an OS does not work, yet, both Linux and Windows halts while loading. This is most likely due to some resource allocation or IRQ routing issue (I'll need to take a look at boot logs to see what's happening) * TianoCore does not boot, it halts the system with a "division by zero" exception displayed on the serial console. I guess it won't be easy to debug this one so it is kind of low priority as of now. The questions I have: * How could I fix the USB keyboard issues with SeaBIOS? Is there some timeout value I could raise to have more stable support for the keyboard? I have tried disabling OHCI & XHCI support in SeaBIOS but that did not help. * I can see a few resources allocation errors on the console output. For some of these errors, the missing resources are actually unused by the board (eg. the secondary & tertiary base address for the environment controller). Shall I allocate the I/O address 0x0 to such devices or simply ignore the errors? * For the SATA controller, coreboot reports that there are 4 memory address spaces that are not being allocated. Checking the devicetree of other similar boards, I can see these resources are not allocated there, either. Is it safe to ignore this error? * Any ideas how to debug the lockup caused by the PCIe Bridge device configuration? What does "cmd 07" mean? * I'd like to read some settings from the CMOS memory both in romstage & ramstage. What's the correct way to do so? Using get_option() seems not to work at all while using read_option_lowlevel() returns a warning that I should use get_option() in non-ROMCC stages. Is there some better way to store user-configurable HW settings? nvramcui looks to be a "user-friendly" tool to configure NVRAM settings, is there a similar user interface available for CBFS, too? Thanks & Regards, Gergely On 4 December 2017 at 18:49, ron minnich <rminnich(a)gmail.com> wrote: > don't forget, you can write code that runs in user mode and drives the > superio. > > This is a handy way to test superio chips you're not sure about. > > use iopl(3) to enable arbitrary Io port access, then inb/outb to try to > get some idea what's going on. > > This is obviously a little limited, since the firmware has already done > lots of setup, but I've been able to learn things using this technique. > > ron > > On Mon, Dec 4, 2017 at 9:43 AM Kyösti Mälkki <kyosti.malkki(a)gmail.com> > wrote: > >> On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss <mail.gery(a)gmail.com> wrote: >> > Hi, >> > >> > I'm working on porting Coreboot to the ASUS AM1I-A motherboard and I'm >> a bit >> > stuck. >> > >> > I could successfully build Coreboot but after flashing the ROM, my board >> > looks to be bricked... >> > >> > Once powering on the board, the CPU fan spins up but then nothing >> happens, I >> > can't see any output on the serial console (the connection was tested >> prior >> > to flashing by running a getty on the COM port and it was working fine). >> > >> >> Common errors: Forgetting to use correct super-IO config base address >> (0x2e vs 0x4e) and not providing 48MHz reference clock for the uart >> baudrate divisor. AMD hardware often uses configurable GPIO pins for >> this purpose, the code copied from biostar/am1ml may not be right for >> asus/am1l-a. >> >> You can dump those GPIO configurations eg. with iotools or even dd >> from /dev/mem. Related datasheets for the Kabini family should be >> available without NDAs. >> >> > The board is not fried as I can load back the vendor firmware and it >> boots >> > up absolutely fine. >> > >> > I'd like to find out why Coreboot would not start but don't know what >> tool >> > would be the most suitable for debugging. >> > >> > The chipset and the CPU is already supported by Coreboot but the SuperIO >> > chip is not. It looks to me the serial interfaces of ITE chips work the >> same >> > for all models so I believe using the common code for ITE SIO chips >> should >> > work but I'm unsure (no datasheet available). >> >> AM1 socket support is a hack anyways, grep for >> FORCE_AM1_SOCKET_SUPPORT. Your mileage may vary. >> >> It's not uncommon that PNP LDNs for the UARTs change within one vendor. >> Did you run util/superiotool and dump SIO settings from vendor boot? >> >> > >> > Shall I use a PCIe serial interface card or rather try EHCI debugging? >> I'm >> > afraid in case the boot process halts at some early stage (like before >> > romstage) then I won't see any useful output using any of those. >> > >> >> EHCI debug should be fine nowadays with AGESA, still not my first >> choice here for you. >> PCIe serial cards are untested, probably do not work early enough to >> be useful for you. >> Traditional serial port debug will also be silent before romstage... >> >> > Using a POST card would be a better approach I think but my board has a >> > single PCIe 4x slot which seems to be unsupported by POST cards I could >> find >> > on the web (except one from a Chinese vendor but it costs about $1k >> which is >> > way too expensive). >> >> Those mini-PCI-e POST cards with 7-seg displays are about 4 USD and >> your mainboard TPM connector seems to carry the required LPC signals. >> Remember to enable and route POSTs to LPC (kconfig POST_DEVICE_LPC). >> >> > >> > Here's my WIP code for reference: >> > >> > https://github.com/kissg1988/coreboot/tree/master/src/ >> mainboard/asus/am1i-a >> > >> > Any idea how to proceed? >> > >> >> Get one of those POST cards, try to show vendor/device ID registers >> from superio on the 7-seg display. >> >> > Thanks, >> > Gergely >> > >> > >> >> HTH, >> Kyösti >> >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > https://mail.coreboot.org/mailman/listinfo/coreboot >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by awokd 18 Dec '17

18 Dec '17

On Mon, December 18, 2017 5:01 am, Matt DeVillier wrote: > On Sun, Dec 17, 2017 at 6:58 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > > >> On 12/17/2017 05:06 PM, Dame Más wrote: >> >> >> Hi, >> >>> The Coreboot BIOS of Purism 13 is open? >>> >>> >> No it isn't, while they do use coreboot the silicon init process is >> entirely blobbed. >> >> Technical merits - is it better than an off the shelf dell laptop? Of >> course, but not better enough to justify even a $30 premium let alone >> the thousands they are charging for a whitebox re-brand. It removes the >> brander (ex: dell) from the firmware trust equation but intel still >> remains and so does ME. >> > > That's a pretty absurd exaggeration. Purism laptops certainly sell at a > premium relative to a Dell (eg) with similar CPU/RAM/SSD, but they don't > sell anywhere near the same volume, so their costs are higher. They also > feature hardware kill switches for wifi/BT and mic/webcam, ship with a > blob-free Debian-based distro, and use coreboot with a disable/neutered > ME. Whether or not you consider those qualities, and supporting a > startup working towards increasing owner control on modern hardware, to > justify the price premium is certainly a valid point of discussion. Purism admits they aren't fully free on https://puri.sm/learn/freedom-roadmap/. One can debate whether they are ever going to be able to accomplish their end goal while supporting proprietary systems like Intel ME/AMD PSP with purchases of their new CPUs etc. They are competing for some of the same market segment of people who don't want to get owned by the Intel ME vulnerability of the week, but can't compete with 100% user controlled options for those who require a fully open platform. Overall, I think they are a net positive. It's doubtful Dell would have started offering ME cleaned laptops without Purism's commercial lead. It would be nice if the dollars ended up going to reward hardware manufacturers working to open the platform instead of closing it, though. My personal purchases will be.

1 0

Re: [coreboot] coreboot support for Minnowboard Turbot E3845
by Zoran Stojsavljevic 18 Dec '17

18 Dec '17

> Aren't there any possibilities to get more debug information out of FSP? https://mail.coreboot.org/pipermail/coreboot/2016-August/081851.html https://www.mail-archive.com/coreboot@coreboot.org/msg46341.html Zoran On Sun, Dec 17, 2017 at 2:56 PM, Michael Graichen < michael.graichen(a)hotmail.com> wrote: > Hey, > > I extracted 906 from original BIOS. > > But it still hangs on after POST 0x92 the same with 907. > > Aren't there any possibilities to get more debug information out of FSP? > > > Best Regards > > Michael > > > > > Am 16.12.2017 um 19:35 schrieb Zoran Stojsavljevic: > > > /proc/cpuinfo tells me that the original image is using microcode: 0x906 > > > but where can I find it? > > I do not have 0x906. Please, try 0x907 (attached .inc). > > Good Luck! > > Zoran > > On Sat, Dec 16, 2017 at 2:49 PM, Michael Graichen < > michael.graichen(a)hotmail.com> wrote: > >> Hey Zoran, >> >> thanks for your help! >> >> Is there some place to look up the connection between CPUID and >> microcode? >> >> I tested M0130679905.inc but still with the same effect. >> >> So I flashed the original Image and booted Linux. >> /proc/cpuinfo tells me that the original image is using microcode: 0x906 >> >> but where can I find it? >> >> Best Regards >> >> Michael >> >> >> >> >> Am 14.12.2017 um 20:25 schrieb Zoran Stojsavljevic: >> >> > for a E3845 Family: 0x06 Model:0x37 Stepping: 0x09... >> >> This is CPUID 0x30679, which uses MCU M0130679901.h (ONLY this one). >> >> You can also try the following MCU: M0130679905.inc (attached). You need >> to convert it to .h >> >> Zoran >> _______ >> >> On Thu, Dec 14, 2017 at 6:15 PM, Michael Graichen < >> michael.graichen(a)hotmail.com> wrote: >> >>> Hey Piotr, >>> >>> I'm glad to read that somebody else is working on the Atoms as well. >>> I'm not sure about my ucode config. At the moment I'm using 5 include >>> files: >>> >>> M0130673322.h >>> M0130678806.h >>> M0130678817.h >>> M0130679901.h and >>> M0230672228.h >>> >>> for a E3845 Family: 0x06 Model:0x37 Stepping: 0x09. >>> I copied the includes from various FSP's and the FSP_GOLD packages. >>> >>> I tried other combinations before but then i had no output on the serial >>> line so I ended up using these five. >>> >>> What is your Familly/Model/Stepping and what are you using for ucode? >>> >>> Best Regards >>> >>> Michael >>> >>> >>> >>> >>> Am 14.12.2017 um 00:04 schrieb Piotr Król: >>> > -----BEGIN PGP SIGNED MESSAGE----- >>> > Hash: SHA512 >>> > >>> > >>> > >>> > On 12/13/2017 07:29 PM, Michael Graichen wrote: >>> >> Hey, >>> > Hi Michael, >>> > >>> >> I've bought a Minnowboard Turbot (quad core / E3845) to start >>> >> developing on the Atom's. >>> >> >>> >> I was hopping that it has support like the Minnowboard Max but it >>> >> get stuck right after FspInitApi(&FspInitParams); in >>> >> coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can >>> >> see is "POST: 0x92" which comes from >>> >> post_code(POST_FSP_MEMORY_INIT); right before >>> >> FspInitApi(&FspInitParams); >>> > I'm not expert in MinnowBoard Turbot, but I play recently with E3826 >>> > and saw similar behavior when incorrect microcode was used (or no >>> > microcode). What are your ucode configuration ? >>> > >>> > Best Regards, >>> > - -- >>> > Piotr Król >>> > Embedded Systems Consultant >>> > https://3mdeb.com | @3mdeb_com >>> > -----BEGIN PGP SIGNATURE----- >>> > >>> > iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAloxsggACgkQsu5x6Weq >>> > nkzfPg/+PM8fk80pbmexWQw5IO4LbDOX4vw5LYkrkeTxh/3T6hAAjBt7KJ6OA4Ft >>> > vW8d/Ll37/r7zutrOXemXZRtxulHy4FL/7aGcDdu8JPxnO4ysLGM0fOZxkZtuyNA >>> > WYI7nS5mYcVdA69driI3rW0cSuGVAy7LiOBIzzV5Z8iWjQXop56cMJiP6In7zayr >>> > 7B5XZ6Ix934AzYihK6hZ5Rz5jZyouKb0NJRQLnRB+MljuL4sLa18bnX5NUBqgDxu >>> > cbw54UYgkgd6CsrbGw3XIGB63k7jYYOUayZwBaqg4QYIxPs798pX5MTe7VMJneFc >>> > kmg+t8HHZxQkaF9YjoVwyS5y4/24FgwQ5bROo/ztNqZMz2q0nK6jd7vQjobFKTVb >>> > Hc7w0jQIY37z3ZConHj9hHeVQ4AILFgpUl+NJj04hekcs4aAwJhbMun7YEAmchkp >>> > cCsv+WvXmOUZwTZR+CoH1xTYSMIX6JkMDZlmlhR/UGlAdpIkxMKQ6MezJXgyihvn >>> > rBBAMDKGvNxeZ00Cf35d+tI9OwDWw/YxYDMV3nx5MzeIkvho4Umg6ey824QlqxBF >>> > D+3wYuiB4ZO/uEViYkW62jFOMHxeTZ9lBNdigPsnuclDiXhvAoA1uImsaLHjNHpQ >>> > xndtfh+FPE3kB6c4koorgXxa3OZacd+4pGDmyjOy7Vl+TZk5hkA= >>> > =r1Ls >>> > -----END PGP SIGNATURE----- >>> > >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> > >

1 0

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Dame Más 18 Dec '17

18 Dec '17

Hello, I understand. I want implement Coreboot for current 7th and 8th generation Intel computers. And if the Pursism BIOS was opensource, I could work with it as a base. However I can not find the source code to work with him. I like GNU/Linux and the opensource because among all we do it better, but if the code is not liberated, I can not speak well of Purism. 2017-12-18 6:01 GMT+01:00 Matt DeVillier <matt.devillier(a)gmail.com>: > On Sun, Dec 17, 2017 at 6:58 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> On 12/17/2017 05:06 PM, Dame Más wrote: >> >> Hi, >>> The Coreboot BIOS of Purism 13 is open? >>> >> No it isn't, while they do use coreboot the silicon init process is >> entirely blobbed. >> >> Technical merits - is it better than an off the shelf dell laptop? Of >> course, but not better enough to justify even a $30 premium let alone the >> thousands they are charging for a whitebox re-brand. >> It removes the brander (ex: dell) from the firmware trust equation but >> intel still remains and so does ME. >> > > That's a pretty absurd exaggeration. Purism laptops certainly sell at a > premium relative to a Dell (eg) with similar CPU/RAM/SSD, but they don't > sell anywhere near the same volume, so their costs are higher. They also > feature hardware kill switches for wifi/BT and mic/webcam, ship with a > blob-free Debian-based distro, and use coreboot with a disable/neutered > ME. Whether or not you consider those qualities, and supporting a startup > working towards increasing owner control on modern hardware, to justify the > price premium is certainly a valid point of discussion. > > >> >> If I was you I would purchase a different coreboot compatible laptop then >> compile and install coreboot while running me_cleaner yourself - this will >> provide a better result for a lot less money as these following laptops >> feature open source silicon init and in the case of the intel models are >> pre-skylake so more of ME can be "cleaned". > > >> One of these laptops is $200 max for one in good condition, vs thousands >> for a Purism 13 - with the cash you save you can also buy a KCMA-D8 gaming >> computer for libre gaming in a VM or otherwise. > > > "better" certainly depends on how one ranks the various qualities of a > given device. If owner-controller trumps all other considerations, > then certainly there are "better" options, but you're not going to find > anything for $200 that is anywhere close in terms of weight, battery life, > screen quality, or using a modern SoC -- that's the tradeoff, and again > something that's worth discussion, but framing it in the context of paying > "thousands" for a Purism device vs $200 for something of equal/better > capability is dishonest and does a disservice to the entire community IMO. >

1 0

Re: [coreboot] Black screen during SeaBIOS boot
by Taiidan＠gmx.com 18 Dec '17

18 Dec '17

On 12/17/2017 02:54 PM, Daniel K wrote: > I assumed this meant I didn't need a vgabios.rom, am I right? For the main AST 2050 video, or a PCI-e card that has an onboard Option ROM (all of them) > Or should I be actually including a vgabios.rom for the on-board VGA even though I never plan on using it? No you don't need it as coreboot supports text mode native init for AST 2050. > An even stranger question: should I be including a vgabios.rom for the PCIe VGA? This seems unlikely because factory BIOSes usually work with new video cards without needing to update the BIOS. You simply need to select "Execute Option ROM's on PCI-e devices" and "Execute VGA Option ROM's" in menuconfig with the appropriate security settings - this will load it from the card and it is what the factory vendor BIOS does. I am not sure how SeaBIOS interacts with those, but I know it should work with grub. > Or is the issue that SeaBIOS doesn't work in text-mode-only? > Maybe I'll give GRUB2 a try, that should work in text-mode-only right? Both work text mode, the "graphics" you see in SeaBIOS is still text it is similar to an ncurses program. I suggest trying GRUB with both those above options and the multiple video adapters option enabled, it is what I use. (FYI You can embed a grub.cfg that searches for and loads other grub.cfg's from your disks) Also "CONFIG_ONBOARD_VGA_IS_PRIMARY" should be N if you wish to use your PCI-e video device to see the payload screens.

2 1

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Taiidan＠gmx.com 18 Dec '17

18 Dec '17

On 12/17/2017 05:06 PM, Dame Más wrote: > Hi, > The Coreboot BIOS of Purism 13 is open? No it isn't, while they do use coreboot the silicon init process is entirely blobbed. Technical merits - is it better than an off the shelf dell laptop? Of course, but not better enough to justify even a $30 premium let alone the thousands they are charging for a whitebox re-brand. It removes the brander (ex: dell) from the firmware trust equation but intel still remains and so does ME. If I was you I would purchase a different coreboot compatible laptop then compile and install coreboot while running me_cleaner yourself - this will provide a better result for a lot less money as these following laptops feature open source silicon init and in the case of the intel models are pre-skylake so more of ME can be "cleaned". One of these laptops is $200 max for one in good condition, vs thousands for a Purism 13 - with the cash you save you can also buy a KCMA-D8 gaming computer for libre gaming in a VM or otherwise. My laptop recs: Lenovo G505S (best choice) - no ME/PSP + open source silicon init Lenovo T420 (performance) - ME cleanable + open source silicon init - Can play new games via an ExpressCard EGPU Lenovo X230 (mobility) - ME cleanable + open source silicon init The T420 supports the better ivy bridge CPU's via coreboot, installing coreboot also removes the silly thinkpad wi-fi whitelist. If you get the X230 you may wish to install the better x220 keyboard mod. I still don't understand as to why purism didn't simply use the AMD FT3 like the G505S, when they released their first laptop it was brand new and very fast...now it is not as fast as skylake but still more than good enough to be useful and definitely better than "free someday in the future" wintel. I don't include the novena on this list due to it not having an IOMMU, although it does have open source firmware. My desktop rec: KCMA-D8 (entirely libre, no ME/PSP, can play the latest games at high settings in a VM with a 4386 CPU and a VM attached graphics card) > Where can I download the source code to understand how it is disabled intel > ME? > Thank you They use a software called me_cleaner (not made by them) to "clean" the ME blob, it is available in the coreboot tree and the v4.6 tarball and can be ran on almost any laptop that doesn't have the boot guard anti-feature[1] no matter if it supports coreboot or not. It is impossible to disable ME/PSP[2], Intel/AMD intentionally made them integral to the boot process they even bring up the main CPU - even google was not able to convince them to open source ME and/or and provide a method to truly disable it. On purisms laptops the ME kernel is still running and it still inits the main CPU pre-BIOS, if it was disabled one could not only remove the full ME blob from the firmware but also physically disconnect the ME core - neither of which one can do on any modern intel platform. There are many companies that sell legitimately owner controlled hardware so it can be done just not with brand new x86-64 - let us hope purism uses the proceeds from their not-really-libre laptops to produce something worthwhile. [1] An anti-feature is something that negatively benefits you, in this case "boot guard" takes away the ability to modify your firmware making a modern intel platform controlled 100% by intel and 0% by you vs an intel system from 10 years ago that was 100% you, an IBM POWER 9 system (ex: TALOS 2) which is 100% owner controlled by you or an AMD system pre-PSP (around pre-2013) which is 100% you. [2] AMD has PSP on their new stuff which is equivilant to ME and just as terrible

3 2

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Taiidan＠gmx.com 18 Dec '17

18 Dec '17

On 12/17/2017 09:01 PM, szbnwer(a)gmail.com wrote: > hi there! :) Hi :D > sooo my understanding says that libreboot is a deblobbed coreboot, Yes -plus the different politics. > you say that those machines you mentioned above are 100% owner > cotrolled, however i only know lenovo t400 is good for libreboot from > that list. is this about a misinterpretation of your words, or what? Yeah it is :[ I included the T420/X230 as they have a few features the G505S lacks that he might need - while they are still more free than a purism they have ME so they aren't owner controlled. I wouldn't consider the T400 owner controlled either although it is closer than the T420 etc, while it boots without an ME kernel I still dislike the present of ME and the non-free EC controller (someone is working on a free software replacement for the G505S EC) All of these below devices have libre firmware besides the G505S which currently requires a blob for video and power management, but it is still owner controlled due to the absence of hardware code signing enforcement. Owner controlled devices: Laptops: Lenovo G505S - average laptop performance Novena - ARM - slow :[ Workstations/Servers: KCMA-D8 - medium KGPE-D16 - high-medium Ultra High Performance Servers/Workstations: TALOS 2 (POWER9) - uber fast and a much better price than intel/amd's new high end server stuff. TYAN Palmetto (POWER 8) - fast IBM Firestone (POWER 8) - very fast POWER 9 is true computing excellence - owner controlled from top to bottom and performance significantly better than x86-64. > my best image about this is that coreboot is owner controlled but not > deblobbed, however the possibility is fully opened - is this right? if > yes, then what parts are not deblobbed and how serious they can be? so > what could i win/lose by letting go the idea of aiming a libreboot > machine and choose a coreboot machine instead? (that i dont know when > i will have enough money for that purpose) Some coreboot boards are owner controlled some aren't, and there are varying amounts of blobs. If one builds for instance the KCMA-D8 with coreboot you have the same result as libre-boot as it doesn't need firmware-blobs to run unless you use a 43xx CPU which needs a microcode update for security reasons. You can get a Lenovo G505S for $200, or you can build a KCMA-D8 libre gaming PC for $500-1000 > an another question is that ive read about the background of the whole > hacking game maybe here maybe elsewhere but most likely from mixed > origins... :D so my understanding says that there is a bunch of > encryption keys that are unremovable (except by intel) maybe based on > something like in that case (complete overwrite of everything included > on the ic that contains the intel me) there is something else that > will miss the original keys. (id appreciate a cleaner vision about > this part, for better understanding, but its not the main question) so > this encryption key is only validating something like headers or > entrance points to the parts of the intel me but not the contents/body > of them. the best that core-/libreboot can achieve is to override the > body parts and we can say then the whole became whitebox and well > known, or there is a next level after the achieved access to entirely > remove it? ME brings up the main CPU on a modern intel platform, no ME no computer. The ME core validates the ME kernel and on newer systems parts of the ME software, ME cleaner removes the parts that aren't validated. It is de-facto impossible to remove/disable ME for a variety of reasons and any effort to do so is wasted and better spent on archs's that can have owner controlled devices such as POWER and ARM. > i dont even know how flashing going on in practise nor in theory, just > trying to figure out things around... does it work like total > copy/write access with the chance of wrecking things around on the > other hand, or its controlling/limiting its own access, and then one > should come over it somehow? where me_cleaner works 100% replacing > could be achieved, just none implemented core-/libreboot yet for the > other machines in th range of a specific range of intel me version? I am not really sure what you mean due to the language barrier. > so many thanks for any kinda help and all the bests for everyone around here! Yeah feel free to ask any questions :]

1 0

Coreboot Purism BIOS is free? open?
by Dame Más 17 Dec '17

17 Dec '17

Hi, The Coreboot BIOS of Purism 13 is open? Where can I download the source code to understand how it is disabled intel ME? Thank you

1 0

Re: [coreboot] Black screen during SeaBIOS boot
by awokd 17 Dec '17

17 Dec '17

On Sun, December 17, 2017 7:54 pm, Daniel K wrote: > > Gave CONFIG_ONBOARD_VGA_IS_PRIMARY=y a try but I ran into the issue you > warned about where it bricks my system: after the boot sequence, the OS > only sees the onboard vga and never uses the PCIe video card. Made sure > by connecting two working monitors. Sorry, I didn't expect both to stop working! > Let me step back a bit and try to understand coreboot and VGA. > > > According to https://www.coreboot.org/VGA_support : > > >> If you run coreboot on a system with on-board graphics, you have to >> embed a VGA on the top level, enter the file name of your option rom >> and the PCI ID of the associated graphics device in the form >> <vendor_id>,<device_id> >> > > However, from https://www.coreboot.org/Build_HOWTO#VGA_support : > > >> On some platforms there's support for native gfx init. A VGA BIOS isn't >> required. > > And on my board's coreboot page > https://www.coreboot.org/Board:asus/kgpe-d16#Features : > > >> Native GFX Init: Partial, Text Mode Only, Now features proper EDID >> parsing. > > I assumed this meant I didn't need a vgabios.rom, am I right? Seems to read that way to me too! > Or should I be actually including a vgabios.rom for the on-board VGA even > though I never plan on using it? An even stranger question: should I be > including a vgabios.rom for the PCIe VGA? This seems unlikely because > factory BIOSes usually work with new video cards without needing to > update the BIOS. PCIe VGA cards have an option ROM (aka blob) in the card's firmware. Most onboard video devices don't have separate firmware, that's why their blob is included in the system's firmware. Ordinarily, Seabios will execute these blobs which then initializes the video cards. However, with this in your Seabios config, I'm not sure how it handles those: # VGA ROM # CONFIG_NO_VGABIOS=y > Or is the issue that SeaBIOS doesn't work in text-mode-only? > Maybe I'll give GRUB2 a try, that should work in text-mode-only right? I'm going to have to defer to the experts.

1 0

Re: [coreboot] Black screen during SeaBIOS boot
by Daniel K 17 Dec '17

17 Dec '17

awokd had issues replying to my last message in the thread via his mailer so I'm including part of his reply here: > There's another setting in your coreboot/.config file called: > CONFIG_ONBOARD_VGA_IS_PRIMARY=y > That might be surfaced somewhere in menuconfig but not sure about your > board. If it's not, you might have to track down its Kconfig and change it > there. Gave CONFIG_ONBOARD_VGA_IS_PRIMARY=y a try but I ran into the issue you warned about where it bricks my system: after the boot sequence, the OS only sees the onboard vga and never uses the PCIe video card. Made sure by connecting two working monitors. Let me step back a bit and try to understand coreboot and VGA. According to https://www.coreboot.org/VGA_support : > If you run coreboot on a system with on-board graphics, you have to embed a VGA on the top level, enter the file name of your option rom and the PCI ID of the associated graphics device in the form <vendor_id>,<device_id> However, from https://www.coreboot.org/Build_HOWTO#VGA_support : > On some platforms there's support for native gfx init. A VGA BIOS isn't required. And on my board's coreboot page https://www.coreboot.org/Board:asus/kgpe-d16#Features : > Native GFX Init: Partial, Text Mode Only, Now features proper EDID parsing. I assumed this meant I didn't need a vgabios.rom, am I right? Or should I be actually including a vgabios.rom for the on-board VGA even though I never plan on using it? An even stranger question: should I be including a vgabios.rom for the PCIe VGA? This seems unlikely because factory BIOSes usually work with new video cards without needing to update the BIOS. Or is the issue that SeaBIOS doesn't work in text-mode-only? Maybe I'll give GRUB2 a try, that should work in text-mode-only right?

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2017