Re: [coreboot] [skylake] Can not turn monitor on
Hi Zheng, On 10/6/18 4:58 AM, Zheng Bao wrote: > Sorry for being unclear. no worries, it seems I wasn't very attentive anyway. I just implied you have an integrated (laptop) panel; maybe because you have a mobile processor or maybe because the 1440x900 resolution is common for lap- tops. Anyway, now that you mentioned VGA... May I assume that you don't have an integrated panel and just want an external VGA monitor to work? > By BIOS stage, I mean I need to see the text "Press ESC for boot menu." > on screen. It also means it needs to boot DOS with display on. > But I can not. I have to wait for the linux to boot. Only Linux > (driver?) can turn the display on. I tried with both vbt from github and The VBT is a configuration file for the VBIOS/GOP and graphics drivers. It has to be adapted for each board, so the one from github would only work by low chance. > extracted from original AMI BIOS. How did you extract it? using uefitool on a BIOS image? or from RAM when the original BIOS booted? > My board uses IT6515FN to transfer the display to VGA. This sounds like something libgfxinit could support. I would just try it. You'd have to enable support for your board like this [1]. Your `Port_List` should be `(DP1, DP2, DP3, Internal)`. `Internal` means the eDP here. If you know exactly to which physical port this IT6515FN is connected, you can also specify only that port. Then, in your .config you should have: CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_VGA_TEXT_FRAMEBUFFER=y If you try that and it fails, please also enable CONFIG_DEBUG_ADA_CODE=y and send us a coreboot log. Nico [1] https://review.coreboot.org/28620 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hi Zvika, In the case of a very limited number of chips, the IFD and GbE regions can be generated, and the ME region skipped entirely (see libreboot/ich9gen). For the others, some reverse engineering may be possible for the IFD and GbE regions but generating even a "me_cleaner" comparable region would require substantial reverse engineering, due to the obfuscation and protection measures in the ME. Essentially these regions are not publicly documented and are probably covered under NDA, and in the case of the ME likely not available unless you're Intel yourself. On 06/10/18 12:50, Zvi Vered wrote: > Hello, > > A bin file burned on a BIOS chip contains "Intel FW": > > Intel FW = IFD +PD+ME/TXE+GBE > > IFD=Intel Firmware Descriptor Table. > PD=Parameters > ME=Management Engine (For "Core" kind of processors). > TXE=Trusted Execution Engine (For "Atom" kind of processors). > GBE=Network card firmware. > > If I'm not mistaken, this package is not supplied within coreboot. > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". > > Where can I find full source code for "Intel FW" ? > > Currently, in order to replace vendor's BIOS we must take binary parts > of the original bin file and then stitch it to coreboot.rom built with > the coreboot project. > > I want to depend only on Intel. > > Thank you, > Zvika > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Zvi, On 10/5/18 8:46 PM, Zvi Vered wrote: > According to the help of flashrom, it works with bin files only. > So I should take coreboot.rom and stitch it to the parts of the original > vendor's bin file. there is no standard for neither .bin nor .rom files. Most often these file-name extensions just mean the file contains raw data. If any program implies a special meaning to .rom or .bin, then that meaning is vendor specific. So to flashrom, .rom and .bin is the same. Flashrom doesn't look at the file contents at all. It just copies them to the flash chip (much like the `dd` command copies file contents no matter what they are). If you tell flashrom to write a complete file that doesn't contain a firmware descriptor, then the system can't boot anymore. But if you have a descriptor and other required firmware parts in the flash already, you can tell flashrom to only flash the BIOS region, e.g.: # flashrom -p ... --ifd -i bios -w coreboot.rom This is just more convenient and reliable than stitching files (but the result should be the same). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
On 10/6/18 6:50 AM, Zvi Vered wrote: > Hello, > > A bin file burned on a BIOS chip contains "Intel FW": > > Intel FW = IFD +PD+ME/TXE+GBE > > IFD=Intel Firmware Descriptor Table. > PD=Parameters > ME=Management Engine (For "Core" kind of processors). > TXE=Trusted Execution Engine (For "Atom" kind of processors). > GBE=Network card firmware. > > If I'm not mistaken, this package is not supplied within coreboot. Right. > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". Yes, mostly. For some platforms, coreboot also replaces reference code of the silicon vendor, but today it's mostly just what an IBV like AMI does. > > Where can I find full source code for "Intel FW" ? Most of the regions you mentioned above don't contain code at all. Beside the BIOS, there is ME/TXE code but Intel provides only binaries for these, AFAIK. > > Currently, in order to replace vendor's BIOS we must take binary parts > of the original bin file and then stitch it to coreboot.rom built with > the coreboot project. > > I want to depend only on Intel. That is possible but will require you to dive even deeper in Intel's platform configuration. I can only advice you to treat each of the firmware parts individually as much as possible. For instance, first try to replace the BIOS with coreboot (while keeping the original other parts), then try to replace the ME/TXE firmware, then the GBE and IFD (the latter both only contain configuration data, AFAIK). You will need an NDA with Intel. Then ask them for their binaries, docu- mentation and (Windows) tools to create your own configuration. Don't underestimate the effort. You'll probably need some months to get your own coreboot running, then few more to read through all the docu- mentation and craft your own IFD etc. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] current state of board/f2a85m
I was not able to build any usable rom from the current master branch of coreboot for f2a85m. Compliation runs smooth but the resulting system does not pass POST(i dont know how to call it in coreboot terms, the system just powers up and dont loads the SeaBIOS payload) .. no useful debug information getable from der TTYS0 as there is no output. anyway to contact the current maintainer of this board? my setup: ASUS F2A85M with A8-6600K and 8GB DDR3 Ram. and early version of coreboot was fine expect the fact it was not able to initialize my Radeon HD7850. grettings the kinky nekoboi -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hello Nathaniel, Nico, Thank you very much for the detailed answers. The vendor's bin file starts with the following pattern: : 0010: 5AA5F00F 03000402 0602100B 20002100 Can you confirm that this is the start of IFD ? Best regards, Zvika On Sat, Oct 6, 2018 at 1:30 PM Nico Huber wrote: > > On 10/6/18 6:50 AM, Zvi Vered wrote: > > Hello, > > > > A bin file burned on a BIOS chip contains "Intel FW": > > > > Intel FW = IFD +PD+ME/TXE+GBE > > > > IFD=Intel Firmware Descriptor Table. > > PD=Parameters > > ME=Management Engine (For "Core" kind of processors). > > TXE=Trusted Execution Engine (For "Atom" kind of processors). > > GBE=Network card firmware. > > > > If I'm not mistaken, this package is not supplied within coreboot. > > Right. > > > > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". > > Yes, mostly. For some platforms, coreboot also replaces reference code > of the silicon vendor, but today it's mostly just what an IBV like AMI > does. > > > > > Where can I find full source code for "Intel FW" ? > > Most of the regions you mentioned above don't contain code at all. > Beside the BIOS, there is ME/TXE code but Intel provides only binaries > for these, AFAIK. > > > > > Currently, in order to replace vendor's BIOS we must take binary parts > > of the original bin file and then stitch it to coreboot.rom built with > > the coreboot project. > > > > I want to depend only on Intel. > > That is possible but will require you to dive even deeper in Intel's > platform configuration. I can only advice you to treat each of the > firmware parts individually as much as possible. For instance, first > try to replace the BIOS with coreboot (while keeping the original other > parts), then try to replace the ME/TXE firmware, then the GBE and IFD > (the latter both only contain configuration data, AFAIK). > > You will need an NDA with Intel. Then ask them for their binaries, docu- > mentation and (Windows) tools to create your own configuration. > > Don't underestimate the effort. You'll probably need some months to get > your own coreboot running, then few more to read through all the docu- > mentation and craft your own IFD etc. > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hello Zvika, The vendor's bin file starts with the following pattern: > : > 0010: 5AA5F00F 03000402 0602100B 20002100 > > Can you confirm that this is the start of IFD ? > The magic "5A A5 F0 0F" at offset 0x10 indicates the start of the IFD. Regards, Angel Pons > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
On 10/6/18 2:46 PM, Zvi Vered wrote: > Hello Nathaniel, Nico, > > Thank you very much for the detailed answers. > > The vendor's bin file starts with the following pattern: > : > 0010: 5AA5F00F 03000402 0602100B 20002100 > > Can you confirm that this is the start of IFD ? Yes, it is (at least the first 20B are distinctive). There is not much public documentation about it ([1] is all I know) but you might find something less public with Google [2]. There's also a lot of open-source code of programs that can parse it [3][4]. Code is usually more accurate than documentation but it explains less about the configuration bits. You'll have to ask Intel for the SPI Program- ming Guide for your particular platform if you want to fully under- stand it and craft your own. Nico [1] https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries_intel.txt [2] "Intel" "SPI" "Programming Guide" *cough [3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c [4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
On Fri, Oct 5, 2018 at 9:53 PM Zvi Vered wrote: > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". > > Just to make it clear, it was not always this way. In 1999, 100% of what we call coreboot did 100% of the tasks, and by 2002 it worked on x86, x86_64, powerpc, and alpha-- all 100% GPL. See slide 17 in https://docs.google.com/presentation/d/1-_cgb4gRhZxl9anxudIgO_NAB80yq-ks4HtOx-zlDz8/edit?usp=sharing from 2012. This table shows the fraction of the ROM that is developed with GPL'ed code. That table was made in 2012; as of 2018, AMD is no more open than intel. Probably around 10% at most of the x86 ROM space consists of GPL code. Starting in 2004, Intel pushed back hard on this open situation and we have ended up where we are today: significant amounts of binary blobs in coreboot images on x86. PLEASE, let's not start another "bad intel!" discussion again. There are lots of people at Intel who are working hard to change back to the more open model. Intel is a business and the higher ups at Intel made what they thought were the right business decisions at the time. We don't agree, and let's leave it at that. I just wanted to point out that in the history of microprocessors, from 1970 to present, this current closed situation is not normal. if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs. ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hi Nico, Thank you very much for the information. Best regards, Zvika On Sat, Oct 6, 2018 at 6:18 PM Nico Huber wrote: > > On 10/6/18 2:46 PM, Zvi Vered wrote: > > Hello Nathaniel, Nico, > > > > Thank you very much for the detailed answers. > > > > The vendor's bin file starts with the following pattern: > > : > > 0010: 5AA5F00F 03000402 0602100B 20002100 > > > > Can you confirm that this is the start of IFD ? > > Yes, it is (at least the first 20B are distinctive). > > There is not much public documentation about it ([1] is all I know) > but you might find something less public with Google [2]. There's also > a lot of open-source code of programs that can parse it [3][4]. Code > is usually more accurate than documentation but it explains less about > the configuration bits. You'll have to ask Intel for the SPI Program- > ming Guide for your particular platform if you want to fully under- > stand it and craft your own. > > Nico > > [1] > https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries_intel.txt > [2] "Intel" "SPI" "Programming Guide" *cough > [3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c > [4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
> On 6 Oct 2018, at 17:42, ron minnich wrote: > [...] > > if you really want 100% open, the only real options at this point are power > 9, RISCV and some ARM CPUs. Ron, thanks for your reasoned reply and the contextual background. I believe this is important when embarking on any project with a legacy. I know of libre-friendly POWER9 and RISC-V options. For example, I am currently learning my way around the Talos II (which is excellent). ARM-based systems have been elusive to me. Could you please give some examples of fully libre-friendly ARM-based boards or systems? Thanks!! Kind regards, Andrew -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] current state of board/f2a85m
There was a status report uploaded about a year ago ( https://coreboot.org/status/board-status.html). Can you verify that the coreboot tree at that commit can boot your system? >From there it will be much easier to find out where things broke. On Sat, Oct 6, 2018 at 5:24 AM kinky_nekoboi wrote: > I was not able to build any usable rom from the current master branch of > coreboot > > for f2a85m. > > Compliation runs smooth but the resulting system does not pass POST(i > dont know how to call it in coreboot terms, the system just powers up > and dont loads the SeaBIOS payload) .. no useful debug information > getable from der TTYS0 as there is no output. > > anyway to contact the current maintainer of this board? > > my setup: > > ASUS F2A85M with A8-6600K > > and 8GB DDR3 Ram. > > and early version of coreboot was fine expect the fact it was not able > to initialize my Radeon HD7850. > > grettings > > the kinky nekoboi > > > > -- > 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] Source code for "Intel Firmware"
It depends on what you mean by fully. If there is a so-called Mask ROM (i.e. initial boot program that's part of the chip itself, not replaceable, you can disassemble it however) and the rest of the chip is fully open, does that count? For my money the ARM chromebooks are still one of the best bets out there for messing about with ARM firmware. On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit < ullbek...@andrewnesbit.org> wrote: > > > On 6 Oct 2018, at 17:42, ron minnich wrote: > > > [...] > > > > if you really want 100% open, the only real options at this point are > power 9, RISCV and some ARM CPUs. > > Ron, thanks for your reasoned reply and the contextual background. I > believe this is important when embarking on any project with a legacy. > > I know of libre-friendly POWER9 and RISC-V options. For example, I am > currently learning my way around the Talos II (which is excellent). > ARM-based systems have been elusive to me. > > Could you please give some examples of fully libre-friendly ARM-based > boards or systems? Thanks!! > > Kind regards, > > Andrew > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
> On 6 Oct 2018, at 22:17, ron minnich wrote: > > It depends on what you mean by fully. If there is a so-called Mask ROM (i.e. > initial boot program that's part of the chip itself, not replaceable, you can > disassemble it however) and the rest of the chip is fully open, does that > count? That's a good start. In my experience, these are what I've mostly seen. Ideally I mean one where the boot loader (and payload?) are not proprietary. Or that an open source boot loader could be used, preferably without added blobs. > For my money the ARM chromebooks are still one of the best bets out there for > messing about with ARM firmware. Yes, I've been looking at getting one for this very purpose, especially as it's already a whole, usable system. Have you any particular recommendations? >> On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit >> wrote: >> >> > On 6 Oct 2018, at 17:42, ron minnich wrote: >> > >> [...] >> > >> > if you really want 100% open, the only real options at this point are >> > power 9, RISCV and some ARM CPUs. >> >> Ron, thanks for your reasoned reply and the contextual background. I >> believe this is important when embarking on any project with a legacy. >> >> I know of libre-friendly POWER9 and RISC-V options. For example, I am >> currently learning my way around the Talos II (which is excellent). >> ARM-based systems have been elusive to me. >> >> Could you please give some examples of fully libre-friendly ARM-based boards >> or systems? Thanks!! >> >> Kind regards, >> >> Andrew -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
There are people on this list who know better than I what the most "open" one is. Anyone out there have some advice? On Sat, Oct 6, 2018 at 3:17 PM Andrew Luke Nesbit < ullbek...@andrewnesbit.org> wrote: > > On 6 Oct 2018, at 22:17, ron minnich wrote: > > It depends on what you mean by fully. If there is a so-called Mask ROM > (i.e. initial boot program that's part of the chip itself, not replaceable, > you can disassemble it however) and the rest of the chip is fully open, > does that count? > > > That's a good start. In my experience, these are what I've mostly seen. > > Ideally I mean one where the boot loader (and payload?) are not > proprietary. Or that an open source boot loader could be used, preferably > without added blobs. > > For my money the ARM chromebooks are still one of the best bets out there > for messing about with ARM firmware. > > > Yes, I've been looking at getting one for this very purpose, especially as > it's already a whole, usable system. Have you any particular > recommendations? > > On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit < > ullbek...@andrewnesbit.org> wrote: > >> >> > On 6 Oct 2018, at 17:42, ron minnich wrote: >> > >> [...] >> > >> > if you really want 100% open, the only real options at this point are >> power 9, RISCV and some ARM CPUs. >> >> Ron, thanks for your reasoned reply and the contextual background. I >> believe this is important when embarking on any project with a legacy. >> >> I know of libre-friendly POWER9 and RISC-V options. For example, I am >> currently learning my way around the Talos II (which is excellent). >> ARM-based systems have been elusive to me. >> >> Could you please give some examples of fully libre-friendly ARM-based >> boards or systems? Thanks!! >> >> Kind regards, >> >> Andrew >> > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Bootblock CMOS default and the checksum algo
Hey all-- Recently, I started the process of enabling CMOS-based runtime config on a board. As this board is native coreboot and it had never used the CMOS in any meaningful sense, the CMOS was wholly zeroed out. Based on this, the bootblock never programs the defaults. Why? Because the checksum algorithm sums with a constant of 0 and simply sums the bytes. This wasn't always the case, but was changed here: http://review.coreboot.org/279 Downstream effects of this can be seen in nvramcui. As the CMOS is zeroed, some enums (like debug_level) do not define a value at zero. As a result, nvramcui ends up with a null pointer deref when trying to set these enums. Questions for the list: 1) Will CMOS reset typically result in zeroed out CMOS? Should we assume that it probably does? Is this a common case? 2) To fix this, bootblock could look at options table checksum and use a different constant or NOT the result. Is this reasonable to do in bootblock? (My opinion is probably not) 3) As a workaround, an image could be used with CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special image acceptable if we assume question 1 is answered "yes"? 4) Should nvramcui be fixed to handle bogus enums? 5) What documentation of this behavior makes sense? Also open to other solutions, thoughts, etc. Depending on the results of this convo, I'll send patches/doc updates over that make sense. TIA, -- William McCall -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
