Re: [coreboot] VGA and Graphics
Igor Skochinsky via coreboot <coreboot@coreboot.org> writes: > Hello Patrick, > > Tuesday, April 4, 2017, 8:54:09 PM, you wrote: > > PR> VBT is documented by intel-gpu-tools. There's intel_vbt_decode > PR> (former intel_bios_decode) available > PR> > https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c > PR> that will print all tables in human readable form. > > Nice find! I did not realize this tool supports that many structures; > for some reason I thought it just prints some general info without details. > > So now that we have a dumper the following should be possible: > 1) make a "decompiler" that would convert VBT from the option ROM into a > human/machine > readable text format > 2) make a "compiler" that would take that text format and create a > binary VBT from it > 3) put the binary VBT into the ACPI IGD OpRegion table ([1], [2]), or > wherever the graphics driver can find it. > I think blobtool would fit that purpose quite nicely on the assumption VBT is already extracted and that VBT has fixed locations for its entries. If one writes a blobtool spec file (which describes the bitfields) it can serve both as a "decompiler" and as a "compiler". >So, basically, an approach similar to ich9gen for the flash >descriptor/gbe. Blobtool handles ICH9 IFD and GBE compilation and decompilation too. ;) >This should allow getting rid of the option ROM if real mode support is >not required. Would great to have indeed, who knows if other OS drivers will mandate VBT one day. Kind regards. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Overheating on f2a85-m
Hi Piotr Kubaj via coreboot <coreboot@coreboot.org> writes: > I've installed Coreboot on ASUS F2A85-M. Everything works fine, but > the CPU overheats when doing something intensive (like video playing) > and the OS crashes. Browsing the internet and watching movies doesn't > make it sweat. I use FreeBSD 11.0-RELEASE and Gentoo Linux. > Would be nice if you had some temperature figures. > My CPU is X4 750k. I lowered the RAM voltage to 1.35V but it doesn't > really help. Enabling power saving features also doesn't make a > difference. Everything works fine on vendor UEFI, so this issue is > specific to Coreboot. Any idea what I can do? > If you notice a difference in CPU fan speed, that would be my guess since it looks fan control (super I/O) is rather minimally configured in coreboot. Kind regards. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2
Hi > > I tried again, this time with SeaBIOS instead of GRUB2 as the primary > payload, and with CoreInfo as a secondary payload. As above, I > selected "Use native graphics initialization" under "Devices" within > `make nconfig`. (See attached .config .) > > The result was the same as above: the backlight came on, but there was > nothing displayed on the screen. > I would not be too surprised if native graphic init is invalid for Nehalem, since looks like a rough copy of ivy/sandy bridge... (A quick look at the code tells me computing PLL divisors is too rough to be right in all cases. When it is too much out range for a display a lit up black screen is typically all you get...) > I do think you are probably right about this issue (i.e. nothing being > displayed on the screen) being due to a failure to initialise the > graphics properly, and I am open to further attempts to overcome the > issue, as my time allows. > One option is to extract the option rom from vendor bios and use that for init. Another is to fix up that native graphic init. Last option is hook up libgfxinit, an alternative Intel display init code written in ada/spark, which might set up display correctly... > Is there anyone on the list who has Coreboot working on an X201 who > would be willing to share their .config file, so that I might see how > they succeeded where I am failing? > > Thanks! Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Rowhammer DRAM Refresh
Philipp Stanner <stan...@posteo.de> writes:
> Hi,
>
> where (which code file) does coreboot set the DRAM-refresh-rate and
> how easy is it for me to change it?
That would be in raminit, which is platform specific. So it depends on
readability of that code whether it's easy to find or not.
Not sure of this is possible with raminits like FSP or MRC.bin provided
in binary only.
>
> A higher refresh rate will decrease the performance but increase the
> protection against Rowhammer.
>
> // Philipp
Some example of how to achieve this on Intel 945 northbridge:
diff --git a/src/northbridge/intel/i945/raminit.c
b/src/northbridge/intel/i945/raminit.c
index b5cce9c429..36dd601fb2 100644
--- a/src/northbridge/intel/i945/raminit.c
+++ b/src/northbridge/intel/i945/raminit.c
@@ -811,32 +811,8 @@ static void sdram_detect_smallest_refresh(struct sys_info
* sysinfo)
{
int i;
- sysinfo->refresh = 0;
+ sysinfo->refresh = 1;
- for (i = 0; i < 2*DIMM_SOCKETS; i++) {
- int refresh;
-
- if (sysinfo->dimm[i] == SYSINFO_DIMM_NOT_POPULATED)
- continue;
-
- refresh = spd_read_byte(get_dimm_spd_address(sysinfo, i),
- SPD_REFRESH) & ~(1 << 7);
-
- /* 15.6us */
- if (!refresh)
- continue;
-
- /* Refresh is slower than 15.6us, use 15.6us */
- if (refresh > 2)
- continue;
-
- if (refresh == 2) {
- sysinfo->refresh = 1;
- break;
- }
-
- die("DDR-II module has unsupported refresh value\n");
- }
printk(BIOS_DEBUG, "Refresh: %s\n", sysinfo->refresh?"7.8us":"15.6us");
}
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] kfsn4-dre: Tested RAM configurations?
Hi Coreboot has not merged K8 and fam10 support so you have to compile for one or the other. (Fam10 being more modern and having a higher amount of maximum cores per cpu package) Daniel Kulesz via coreboot <coreboot@coreboot.org> writes: > Hi all, > > the Wiki page for the kfsn4-dre is somewhat incomplete. It mentions that > > "K8 processors currently require specific RAM configurations to work > correctly. " > I don't have this particular board but K8 raminit code is a bit unflexible with respect to using different dimms and will very quickly disable a dimm if they are unmatched. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Where to get ME image/flash descriptors for the x220?
"taii...@gmx.com" <taii...@gmx.com> writes: > Well I managed to download the latest BIOS from the lenovo site, which > includes an ME update now the issue is that I can't seem to figure out > how to extract it from the .FL1 and .FL2 files. > Those might have a length too long to fit a flash so you need to trim those down before using ifdtool on those (If they contain and ifd of course) so depending on size of rom dd if=FL1(or 2)file of=vendor_bios.rom bs=1 count=xM and then ifdtool -x vendor_bios.rom > I would also like to know as to how I can re-flash the EC firmware if > that could potentially cause problems, I of course do not know if it > has DMA. > Only existing tool to flash EC is using vendor tool. EC are only accessed trough port mapped IO (or on newer ones also via memory mapped IO). EC itself does not have DMA afaik. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?
Paul Menzel via coreboot <coreboot@coreboot.org> writes: > I think most of the time is spent in RAM initialization. > >1. Do board owners with similar amount of memory (independent of the > board) have similar numbers? >2. What are the ways to improve that? Is it possible? For example, can > the modules be probed in parallel (if that isn’t done already)? > I'm not the right person to answer this since I don't know this code/hardware that well, but on modern Intel hardware native code uses the MRC cache to store dram training results and restore those on next boots (and resume from suspend) if no change in dimm configuration was detected. Maybe something like this could also be applied here (or maybe it's already the case since it includes code to access spi flash)? > > Thanks, > > Paul Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l
Stefan Reinauer <stefan.reina...@coreboot.org> writes: > * i1w5d7gf38...@tutanota.com <i1w5d7gf38...@tutanota.com> [170226 21:59]: >> Hardware: Gigabyte g41m-es2l, latest coreboot git, latest seabios git, two >> nvidia gpu cards tested >> >> I tried to use some external GPU on a g41m-es2l to get some digial screen >> output. It does not seem to work. When having build coreboot with native >> vga-init for the internal intel gpu, i never get a output from the nvidia >> card. >> When i connect the analog VGA cable to the internal intel gpu and boot up i >> can >> see many nouveau (memory-space?) errors. Both GPUs (nvidia and intel) are >> then >> enabled at once. Kernel 4.10 cant boot. >> >> I tried removing the native vga-init. The only change is then that the Intel >> GPU works only when the kernel have load. Nvidia card deliver still same >> errors. >> >> With OEM-bios the intel card gets disabled and a PCIe GPU works fine. > > Please provide coreboot boot logs. > > Stefan Actually https://review.coreboot.org/#/c/18504/ https://review.coreboot.org/#/c/18511/ (not sure if needed) and https://review.coreboot.org/#/c/18513/ (works but might be improved) fix this issue. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l
Arthur Heymans <art...@aheymans.xyz> writes: > <i1w5d7gf38...@tutanota.com> writes: > >> Hardware: Gigabyte g41m-es2l, latest coreboot git, latest seabios git, two >> nvidia gpu cards tested >> >> I tried to use some external GPU on a g41m-es2l to get some digial >> screen output. It does not seem to work. When having build coreboot >> with native vga-init for >> the internal intel gpu, i never get a output from the nvidia >> card. When i connect the analog VGA cable to the internal intel gpu >> and boot up i can see many >> nouveau (memory-space?) errors. Both GPUs (nvidia and intel) are then >> enabled at once. Kernel 4.10 cant boot. > > Indeed the internal GPU should be disabled if an external GPU is > detected. Afaik there is only one northbridge that currently does this > for desktop boards which can have a wide variety of things in that slot > and this is i945. (It disables integrated GPU in romstage) Maybe this > code can be reused? > Seems I was wrong. Adding a correct disable operation to the internal graphic device should do it. The allocator will detect 2 graphic devices and if internal one has a disable op, it will be disabled. This might fix it: https://review.coreboot.org/#/c/18504/ -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l
<i1w5d7gf38...@tutanota.com> writes: > Hardware: Gigabyte g41m-es2l, latest coreboot git, latest seabios git, two > nvidia gpu cards tested > > I tried to use some external GPU on a g41m-es2l to get some digial screen > output. It does not seem to work. When having build coreboot with native > vga-init for > the internal intel gpu, i never get a output from the nvidia card. When i > connect the analog VGA cable to the internal intel gpu and boot up i can see > many > nouveau (memory-space?) errors. Both GPUs (nvidia and intel) are then > enabled at once. Kernel 4.10 cant boot. Indeed the internal GPU should be disabled if an external GPU is detected. Afaik there is only one northbridge that currently does this for desktop boards which can have a wide variety of things in that slot and this is i945. (It disables integrated GPU in romstage) Maybe this code can be reused? > > I tried removing the native vga-init. The only change is then that the > Intel GPU works only when the kernel have load. Nvidia card deliver > still same errors. Whether the hardware is initialised or not makes no difference to the fact that is enabled/disabled. Linux is sometimes unhappy if no form of initialisation (option rom or native) has been performed. > > With OEM-bios the intel card gets disabled and a PCIe GPU works fine. OEM bios does the right thing :) -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Freeze after few bootups
<i1w5d7gf38...@tutanota.com> writes: > Hardware: gigabyte g41m-es2l, coreboot git, seabios-git, native vga > > I have the problem that the computer is freezing after few boots. Its hanging > then at every boot in this stage: > > > > tWR: 5 > > tRFC: 35 > > tWTR: 4 > > tRRD: 3 > > tRTP: 4 > > Channel 0 possibly not in self refresh > > Channel 1 possibly not in self refresh > > Done clk crossing > > Done launch > > Done timings > > DimmA populated only in channel 0 > > No dimms in channel 1 > > Done ODT > > Done pre-jedec > > MRS... > > CH0: Found Rank 0 > > Nothing happens afterwards. That is a very weird place for raminit to hang... (JEDEC init) > > I replaced the RAM to an other one. Turned it on, it then reset once: > > > tRAS: 18 > > tRP: 6 > > tRCD: 6 > > tWR: 6 > > tRFC: 51 > > tWTR: 4 > > tRRD: 3 > > tRTP: 4 > > Reset... > This could happen if power was cut off during a previous raminit. > and hangs again at this stage: > ... > > Done ODT > > Done pre-jedec > > MRS... > > CH0: Found Rank 0 > > I disconnected the PSU, removed the CMOS battery and wait few minutes. Then > it stops hanging at this stage. > Though some raminit results are stored in CMOS, those are only used later in raminit. This leads me to think it might be a hardware issue? > I had this problem also on an other g41m-es2l mainboard with latest libreboot > image installed. So it does not seem to be hardware related and not fixed in > latest > coreboot. > > Anything i could do to help fixing this bug? I have never seen anything like this on the very same board I own, so I don't know how to reproduce or fix this... sorry if I send this twice, but I forgot to put coreboot@coreboot.org in CC. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Freeze after few bootups
<i1w5d7gf38...@tutanota.com> writes: > Hardware: gigabyte g41m-es2l, coreboot git, seabios-git, native vga > > I have the problem that the computer is freezing after few boots. Its hanging > then at every boot in this stage: > > > > tWR: 5 > > tRFC: 35 > > tWTR: 4 > > tRRD: 3 > > tRTP: 4 > > Channel 0 possibly not in self refresh > > Channel 1 possibly not in self refresh > > Done clk crossing > > Done launch > > Done timings > > DimmA populated only in channel 0 > > No dimms in channel 1 > > Done ODT > > Done pre-jedec > > MRS... > > CH0: Found Rank 0 > > Nothing happens afterwards. That is a very weird place for raminit to hang... (JEDEC init) > > I replaced the RAM to an other one. Turned it on, it then reset once: > > > tRAS: 18 > > tRP: 6 > > tRCD: 6 > > tWR: 6 > > tRFC: 51 > > tWTR: 4 > > tRRD: 3 > > tRTP: 4 > > Reset... > This could happen if power was cut off during a previous raminit. > and hangs again at this stage: > ... > > Done ODT > > Done pre-jedec > > MRS... > > CH0: Found Rank 0 > > I disconnected the PSU, removed the CMOS battery and wait few minutes. Then > it stops hanging at this stage. > Though some raminit results are stored in CMOS, those are only used later in raminit. This leads me to think it might be a hardware issue? > I had this problem also on an other g41m-es2l mainboard with latest libreboot > image installed. So it does not seem to be hardware related and not fixed in > latest > coreboot. > > Anything i could do to help fixing this bug? I have never seen anything like this on the very same board I own, so I don't know how to reproduce or fix this... Sorry if I send this twice. I forgot to put coreboot@coreboot.org in CC. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T520 2630QM 16GB DIMM
Thomas Richter <coreb...@tricnet.de> writes: > Hi, > > Zitat von Arthur Heymans <art...@aheymans.xyz>: > >>> TL;DR - Has anybody either successfully used 16GB DDR3 modules on >>> SandyBridge, can rule it out, or has ideas about how to dig deeper? >> >> According to Sandy bridge datasheets only up to 4GB DDR3 technology is >> supported, which makes it possibly to use dimms with 2 ranks, with each >> rank having a capacity of 4GB, hence max 8GB per DIMM. >> This is a hardware limitation. > > Thank you for your answer. That's what I also read, but here it is > stated that some Asus Sandy Bridge boards support such modules: > > http://www.prnewswire.com/news-releases/first-8gb-ddr3-components-and-16gb-unbuffered-dimms--so-dimms-by-im-intelligent-memory-266613731.html > > Is Sandy Bridge E so different from Sandy Bridge? Would it be possible Sandy Bridge E are high end desktop/server CPUs that have a different socket (lga2011) and likely a different memory controller (4 channels instead of 2). A quick look at datasheet says nothing about maximum rank size. > to replace the 2620QM with an Ivy Bridge CPU? Afaik that should be possible since the CPU is socketed on that model but won't overcome your issue. (same limitation) > > Best, > > Thomas -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] T520 2630QM 16GB DIMM
t...@tricnet.de writes: > Hi, > > TL;DR - Has anybody either successfully used 16GB DDR3 modules on > SandyBridge, can rule it out, or has ideas about how to dig deeper? > > I recently bought 2 crucial 16GB DDR3 SODIMM modules to upgrade my > T520 (2630QM CPU) to 32 GB. As it didn't work I did some research and > found a couple of postings blaming the problem on Intel not providing > proper memory reference code (e.g. > http://forum.notebookreview.com/threads/upgrading-ram.756463/page-2) > preventing the BIOS from initializing the RAM. > > When I looked for alternative BIOSes I came across coreboot. Compiled > and installed it - works fine with 2*8GB modules. With one or two 16GB > modules I still saw the SeaBIOS info but then it crashed. Adding > memtest as a secondary payload and starting it worked, but memtest > crashes instantly when it starts testing. > According to Sandy bridge datasheets only up to 4GB DDR3 technology is supported, which makes it possibly to use dimms with 2 ranks, with each rank having a capacity of 4GB, hence max 8GB per DIMM. This is a hardware limitation. <#secure method=pgpmime mode=sign> Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Warning: Changed changed cmos.layout on many systems
Hi In patch [1] "util/nvramtool: Bail out on unaligned multi-byte entries" was found that coreboot does not support options that span multiple bytes and are not aligned. I tried to fix the affected boards by this in [2]. I modes some options around in cmos.layout of some boards.This can be a pain for users since it can result in unexpected changes in settings, since the RTC nvram often remains the same with a new cmos.layout. To make sure that your RTC nvram settings are correct after this gets merged you can have nvramtool use the layout file from the tree against which you can set settings: nvramtool -y src/mainboard/"your_vendor"/"your_board"/cmos.layout -a and adapt the settings accordingly using (-w). I don't think nvramtool has an option to use cmos_layout.bin from the cbfs of an image to change options on the RTC nvram. Such an option would be desirable though. In [2] an idea was proposed of a script that can automatically handle such migration. I'm quite fond of that idea. Any thoughts? The affected systems are: adi/rcc-dff amd/serengeti_cheetah_fam10 asus/kcma-d8 asus/kfsn4-dre asus/kgpe-d16 esd/atom15 hp/dl165_g6_fam10 intel/littleplains intel/minnowmax intel/mohonpeak kontron/ktqm77 lenovo/t400 lenovo/x200 msi/ms9652_fam10 pcengines/apu1 supermicro/h8dmr_fam10 supermicro/h8qme_fam10 [1] "util/nvramtool: Bail out on unaligned multi-byte entries" https://review.coreboot.org/#/c/18246/ [2] "mb/*/*/cmos.layout: Make multibyte options byte aligned" https://review.coreboot.org/#/c/18321/ Kind regards --- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Back to original BIOS
ron minnich <rminn...@gmail.com> writes: > We really need to start warning people when the flash a thinkpad that > it is very important to save the old flash image. It is somewhat thinkpad specific whether the bios extracted from the update tool will work. On X60 I have had no success with it. On X200 it sort of works to flash the vendor bios extracted from update .exe. You can even just flash bios region and leave ifd, gbe (and me) alone. (Though I have had it not being able to boot and complain about some pxe stuff) Note: on x200 there exists a modified (whitelist removed) bios which does not write protect its bootblock. With this it is possible to flash the vendor bios without having to rely on an external programmer to re-flash coreboot. Backup are essential! -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Warning: changed location of EC nvram settings on thinkpad X60 and T60
Hi EC nvram parameters on Lenovo thinkpad X60 and T60, which allow to configure things like wlan, bluetooth, trackpoint, etc are not checksummed. This means that defaults for these parameters are never applied when the checksum is invalid, which happens for instance when cmos is cleared or when coming from vendor bios. This patch https://review.coreboot.org/#/c/17041/ puts these parameters in the checksummed area to overcome this issue. A problem with this is that the checksum is most likely already valid so that after this patch these nvram parameters will be at whatever the nvram currently is at these locations. To overcome this issue either: - have coreboot set defaults on next boot by making checksum invalid: "nvramtool -c 0" where 0 is a checksum which is hopefully not correct - reboot and manually set your desired nvram settings "nvramtool -w wlan=Enable, nvramtool -w bluetooth=Enable, etc" Kind regards ------ Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Removing ME on G45 desktop chipset - same as GM45 mobile?
"taii...@gmx.com" <taii...@gmx.com> writes: > I am wondering if the procedure for removing ME on a GM45 mobile > chipset motherboard would work on its desktop siblings, has anyone > done this before? I have a G45FC from Intel which has an X4500HD > graphics chipset and ICH10R southbridge. ICH10 supports descriptorless mode just like ICH9, so like ICH9 you can probably modify the firmware descriptor to boot without updating ME firmware, or simply remove the firmware descriptor. No idea if the 'procedure?' to do this would be the same. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Petitboot based bootloader
Hi I have been working on building a Petitboot, a kexec bootloader, [0] based Linux payload using the Buildroot build system to produce a nice bzImage that contains both linux and the initrd. It is inspired by the Raptor Enginering HOWTO [0] and is based on op-build [1], the tool for building OpenPOWER firmware, which also uses Buildroot and Petitboot. One of the advantages of Petitboot is that it is fairly simple and intuitive to use and does not require complex configuration like grub does, while still providing a large range of hardware support since it uses linux at its core. A disadvantage is that a Linux + initrd payload takes up quite a bit of space. A fairly stripped down kernel + initrd takes up ~6.9M in the current Buildroot + Linux configuration I have. So a large flash chip or replacing the flash with a larger one is recommended. Coreboot can directly use this Linux payload or first load SeaBIOS which can then chainload the Linux payload. It is still very much a WIP and is currently aimed at Intel hardware, but with a kernel configuration tuned to your target it should work fine. The repo + initial documentation: https://github.com/ArthurHeymans/petitboot_for_coreboot [0] Petitboot: A kexec based bootloader, https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html [1] Creating firmware images with petitboot and coreboot https://secure.raptorengineering.com/content/kb/1.html [2] OpenPower Firmware Build Environment https://github.com/open-power/op-build Kind Regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ISOLINUX gfx problems under qemu/coreboot/SeaBIOS
Jonathan Neuschäfer <j.neuschae...@gmx.net> writes: > > I think I was able to reproduce the problem, when Philipp described it > on IRC: > > 1. checkout coreboot from git[1], or run make clean && rm .config > > 2. make menuconfig, select Emulation/QEMU-i440fx. SeaBIOS will >automatically be selected. > > 3. make > > 4. Test with QEMU. I'm using QEMU 2.6.0 from Debian testing (a.k.a. >stretch) on an x86_64 laptop. Both of the tested CDs use ISOLINUX. > > 4.1.1. get xubuntu-16.04.1-desktop-amd64.iso[2] > > 4.1.2. qemu-system-x86_64 -cdrom xubuntu-16.04.1-desktop-amd64.iso -m 512 > A splash screen is shown, and then a graphical boot menu, which allows > to select language, different boot modes, kernel command line, etc. > > 4.1.3. qemu-system-x86_64 -cdrom xubuntu-16.04.1-desktop-amd64.iso -m 512 > -bios build/coreboot.rom > The splash screen doesn't appear; instead an error is shown: > > graphics initialization failed > Error setting up gfxboot > boot: > > 4.2.1. get debian-live-8.2.0-amd64-lxde-desktop.iso[3] > > 4.2.2. qemu-system-x86_64 -cdrom debian-live-8.2.0-amd64-lxde-desktop.iso > A graphical boot menu is shown. > > 4.2.3. qemu-system-x86_64 -cdrom debian-live-8.2.0-amd64-lxde-desktop.iso > -bios build/coreboot.rom > ISOLINUX fails to present a graphic menu and falls back to a > text-based menu. A quick test shows me that selecting CONFIG_SEABIOS_VGA_COREBOOT is the culprit. This change https://review.coreboot.org/#/c/16965/ selects this by default when native graphic init is used but apparently needs an exception for QEMU. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l
Nico Huber <nico.hu...@secunet.com> writes: > Hi Arthur, > > > This is just a synchronization point. The wbinvd() is there to ensure > that the memcpy() above has reached real RAM before the program con- > tinues. > > As this fails right after resources have been assigned to all devices, I > suspected a resource conflict but couldn't find any trouble in your log. > > Another thing that can cause trouble is the MTRR configuration. I have > no idea in which state they are / should be in your case, though. It really is a raminit issue. I tested with a 800MHz fsb (does not even get to ramstage) and a 533MHz fsb cpu which just works (this is a 1067fsb cpu with tape on bsel0 pin to make it select 533fsb). So unless 945gc raminit gets fixed, this port is quite useless. This i945 raminit.c seems to have a lot of code specific for 667fsb (laptops only) and 533fsb (Intel d945gclf atom board). I guess I'll have to run vendor through serialICE and see how MCHBARS are configured with inteltool with 800fsb and 1067fsb cpus. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l
Zoran Stojsavljevic <zoran.stojsavlje...@gmail.com> writes: > Hello Arthur, > > CPUID 1067x? Penryn? > https://en.wikipedia.org/wiki/Penryn_(microprocessor) ?! This is indeed the cpu which I used to run tests with. This board should also work with older LGA775 cpu I think. (even though coreboot has problems with CAR on this P4 HT 630 I also tried) > It is long time off any radar screen for INTEL IOTG support, I can tell to > you this... Started production in 2007! :-(( WTH you need Coreboot on this > one? What is INTEL IOTG support? > "The WBINVD instruction is a privileged instruction. When the processor is > running in protected mode, the CPL of a program or procedure must be 0 to > execute this instruction. This instruction is also a serializing instruction > (see "Serializing Instructions" in Chapter 8 of the IA-32 Intel Architecture > Software > Developer's Manual, Volume 3)." > > Question to you: do you execute this instruction (WBINVD) in Ring 0 (kernel) > mode? If you do, and it still hangs, I have for you a good suggestion: try to > replace > WBINVD with INVD and see if you'll hang (simple logic stands behind > what I read there: > http://x86.renejeschke.de/html/file_module_x86_id_325.html). No idea, but I can certainly try it. > If you hang: your problem is for sure/100% NOT raminit (in other words MRC); > If you do NOT hang, and continue: raminit (MRC) might be (but not > certainly???) your problem. If you hang later (while accessing DDRAM), > then it is obvious! ;-) What I don't understand is that this is just southbridge code which is used by other boards too and that this instruction causes no issues to those other boards in the coreboot tree (like thinkpad x60). Having read all the i945 raminit code (this is not MRC but native coreboot code AFAIK) it does seem to be written with 667MHz fsb (945gm laptops like thinkpad x60)and 533MHz fsb (945gc inteld945gclf) in mind. So I will soon try to confirm this theory with 533MHz fsb cpu. > > Good luck with this one, > Zoran Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l
Hi I'm trying to port coreboot to the gigabyte ga-945gcm-s2l, which has a 945gc northbridge, a ich7 southbridge and a ite it8718f sio. I'm trying all this with a 1067fsb cpu, so in that last aspect there is no precedent in coreboot. I encountered some raminit issues where the MCHBAR(CLKCFG) was incorrectly written, but this was fixed in https://review.coreboot.org/#/c/16940/. Right now I'm stuck in smm_init in southbridge/intel/i82801gx/smi.c. The boot process completely hangs when wbinvd() is called which supposed to "Write Back and Invalidate Cache" according to http://x86.renejeschke.de/html/file_module_x86_id_325.html. What does this mean? Did the raminit not work? -- Kind regards Arthur Heymans coreboot.log13 Description: coreboot.log -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Getting an WXGA+ LED MVA panel to work on T400: "G141C1-L01"
Merlin Büge <t...@bluenox07.de> writes: >> Not sure why Linux doesn't get the display running though. But as Linux >> sometimes reuses register settings set by the firmware there is a slight >> chance that fixing coreboot would make it work in Linux too. > > > You mean, despite the kernel log messages (which say 104500), > it might be that Linux is actually using the clock settings from coreboot, > that > is 87075? Linux should be able to modeset the display (mostly) independently from coreboot (misconfigured) settings. So if the display does not work in linux I think something else is wrong. > So, to check for that - could I temporarily hardcode the correct clock > settings > in coreboot/libreboot? > This https://review.coreboot.org/#/c/16741/ should set graphic clock correcly for g4x gpu's. Since it does the same as linux I don't expect it to work but feel free to try it. There is a slight chance that this display uses a single channel LVDS, in this case the p2 clock divisor needs to be set to 14 instead of 7, which you can hardcode in src/northbridge/intel/gm45/gma.c > > [0] > http://www.display-solution.com/pdf/tft-displays/Chi%20Mei%20Innolux/G141C1-L01_V2.0_20100802.pdf > From what I can understand from datasheets this is a dual channel LVDS (as expected)... > > > > -- > Merlin Büge <t...@bluenox07.de> Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ps2 keyboard init in seabios
Hi
In a few boards (at least x60, x200, google peppy and likely more) ps2 keyboard
does not
work consistently in seabios unless a timeout value is set (3sec default for
x60),
which adds a file etc/ps2-keyboard-spinup containing the max timeout
value.
A way to fix this to add this delay in the Kconfig of all the concerned
boards.
Requiring an extra file in cbfs for a board to work with a payload is
less than ideal, because this is inconsistent.
A simple way to fix this is to change seabios to have a non-zero timeout for
ps2-keyboard init, when compiled for coreboot.
diff --git a/src/hw/ps2port.c b/src/hw/ps2port.c
index d5504f7..ede09f0 100644
--- a/src/hw/ps2port.c
+++ b/src/hw/ps2port.c
@@ -478,7 +478,8 @@ ps2_keyboard_setup(void *data)
/* --- keyboard side */
/* reset keyboard and self test (keyboard side) */
-int spinupdelay = romfile_loadint("etc/ps2-keyboard-spinup", 0);
+int spinupdelay = romfile_loadint("etc/ps2-keyboard-spinup",
+ !CONFIG_COREBOOT ? 0 : 3000);
u32 end = timer_calc(spinupdelay);
This solution is not a good one since if a board does not have a
keyboard, this will delay the startup of 3 seconds.
My idea was to add an entry to coreboot tables which tells whether or
not a board has a ps2 controller.
That way this information can be passed to seabios, which would then
again be a more universally working binary(not relying on files in cbfs for
correct behavior).
Kind regard
--
Arthur
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] RFC: implementing a way to force external EDID use.
Hi In Linux it is possible to load an EDID externally. Coreboot can currently not do this. Do you think it is worth implementing this feature? An EDID file is a bit to big (128 bytes) to fit in nvram so it would have to go in cbfs. Where in the code do you think this setting should be implemented: NB code, read_edid in drivers, decode_edid in lib, somewhere else? How do you think this feature should be turned on: nvram option or build option? Thank you for your comments -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Documentation on msr bits on intel cpuid 6ex and later
Hi In the code for intel model_6ex there is a comment "TODO Do we want Deep C4 and Dynamic L2 shrinking". On later targets (6fx and 1067) this is done setting some bits in IA32_MISC_ENABLE and MSR_PMG_CST_CONFIG_CONTROL msr. It tried setting the same bits, which should upgrade C2 to C2E and C4 to C4E. The results is that the C2 state consumes noticeably less power. (C4 remains similar in power consumption) Those msr bits are mentioned in intel datasheets on those cpus: http://download.intel.com/design/mobile/datashts/30922106.pdf I can't find documentation on those bits. In the "Intel® 64 and IA-32 Architectures Software Developer’s Manual" those bits are marked as reserved... I would like to know more about this, so if someone can help me on this... -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] gfx_uma_size on GM45
Hi
On gm45 targets there are some option to set different vram option using
the cmos parameter gfx_uma_size. The northbridge code however allows many
more option, ranging for 1M to 352M.
So I tried making them an on option by modifying cmos.default and the
northbridge code that uses those cmos bits.
Now the size of this cmos parameter has to be increased for 3 to 4 bits
to be able to hold all those options.
My problem is that only the 3 smallest bits from the cmos parameter are
used.
The problem is truly there because hardcoding the vram size instead
works fine.
these are the changes I tried (at 256M it forgets highest bit and is
read as 0 in cmos and 1M is used):
--- a/src/mainboard/lenovo/x200/cmos.layout
+++ b/src/mainboard/lenovo/x200/cmos.layout
@@ -77,9 +77,9 @@ entries
940 1 e 1uwb
# coreboot config options: northbridge
-941 3 e 11 gfx_uma_size
+941 4 e 11 gfx_uma_size
-944 8 h 0volume
+945 8 h 0volume
# coreboot config options: check sums
984 16 h 0check_sum
@@ -125,12 +125,19 @@ enumerations
9 1 Primary
100 AHCI
101 Compatible
-110 32M
-111 48M
-112 64M
-113 128M
-115 96M
-116 160M
+110 1M
+111 4M
+112 8M
+113 16M
+114 32M
+115 48M
+116 64M
+117 128M
+118 256M
+119 96M
+1110160M
+1111224M
+1112352M
--- a/src/northbridge/intel/gm45/igd.c
+++ b/src/northbridge/intel/gm45/igd.c
@@ -153,10 +153,10 @@ void igd_compute_ggc(sysinfo_t *const sysinfo)
/* Graphics Stolen Memory: 2MB GTT (0x0300) when VT-d disabled,
2MB GTT + 2MB shadow GTT (0x0b00) else. */
if (get_option(, "gfx_uma_size") != CB_SUCCESS) {
- /* 0 for 32MB */
- gfxsize = 0;
+ /* 4 for 32MB, default if not set in cmos */
+ gfxsize = 4;
}
- sysinfo->ggc = 0x0300 | ((gfxsize + 5) << 4);
+ sysinfo->ggc = 0x0300 | ((gfxsize + 1) << 4);
if (!(capid & (1 << (48 - 32
sysinfo->ggc |= 0x0800;
}
Kind regards
--
Arthur Heymans
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
