August 2014 - coreboot - mail.coreboot.org

bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.
by The Gluglug Aug. 27, 2014

Aug. 27, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using 6725 to enable text-mode gfx init on X60 when using native graphics initialization. Affected machines: X60, T60. It may also affect: macbook21/macbook11, X60 Tablet This relies on the (merged) patch 6723 that enables text-mode graphics initialization on i945 platforms. The code is there. I then disabled "Keep VESA framebuffer" in menuconfig, to enable text-mode. error: no video mode activated This is what I see when I try to use the net install iso for Debian with the isolinux parser in grub. I also saw the same thing when trying to start Trisquel 6 isolinux menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from seabios's rom that I built). See attached image of what happens when I try to boot the net install from Debian (same thing happens with the Trisquel net install), using the following: linux (usb0)/install.386/vmlinuz initrd (usb0)/install.386/initrd.gz boot As you can see, there is quite a lot of flicker and parts of the screen are missing or corrupt. I think this is related to the issue above ("error: no video mode activated"). The net install for Debian and Trisquel both work when using corebootfb initialization method, but they fail (as seen in the image) for text-mode method. In case the attachment was scrubbed by the mailing list, I also put it here: http://dev.libreboot.org/x60txtmode.jpg Trisquel graphical install works (I wasn't able to figure out how to boot the Debian graphical install). I also enabled it for T60 (adding the keep/drop vesa fb option for t60/Kconfig, based on 6725, and cherry picking 5345) and the same behaviour was observed there. What does work in text-mode init (tested): memtest86+ and grub invaders. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+1tNAAoJEP9Ft0z50c+UEpwH/jpnNQqSS1IfbU0K2y+y2YcJ NS8j1MyYCyrVjFh+bVEbmd6ObDjM0lo8GSPeqlcMY0GvPj7YwXUf0ZGMnlDbj3KP zazDpqMQaCnbcFApg6cxqCkxA1CNeRFlpFslkzt4cht7nBpkV/kdGNnJ2XLfIlDn AwhMVOK/pT6osgVO5hc2VUDrHBnO2LLHE3K0KPsbyMVWWqvWeLPZWZ0baZY60OAk 4g+NxyZMWtBhSVmcrrVQu1NjqXlnYUALx7XxKuB9fsjr+HQfHWoH0ZBYUYuGHrXA /ATYQuuP06teeur70ya/sN1t/e0czU1CBGV3yp57VhvomQtlQTucp9f+am/Gmxw= =POgA -----END PGP SIGNATURE-----

2 3

Re: [coreboot] apologies in advance for a question I may have asked
by Stefan Reinauer Aug. 27, 2014

Aug. 27, 2014

* ron minnich <rminnich(a)gmail.com> [140827 18:43]: > I need to set up qemu with a 64MiB ROM. > > I figure supporting EFI has made QEMU capable of such things, but if > anyone has direct experience with this, please let me know. I tried it > a few years back (2008) and it did not work at all ... I guess worst > case I can make an NE2000 "device" with a giant ROM, but I'd prefer to > just do it with a 64MiB device at top of 4GiB address space. I assume you don't mean MBit, so you're out of luck. Most likely with both the NE2000 approach and the system firwmware approach. >From hw/i386/pc_sysfw.c: /* We don't have a theoretically justifiable exact lower bound on the * base * address of any flash mapping. In practice, the IO-APIC MMIO range is * [0xFEE00000..0xFEE01000[ -- see IO_APIC_DEFAULT_ADDRESS --, leaving * free * only 18MB-4KB below 4G. For now, restrict the cumulative mapping to * 8MB in * size. */ #define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 8*1024*1024)) Stefan

2 1

Re: [coreboot] disabling bios usb stack
by Scott Duplichan Aug. 27, 2014

Aug. 27, 2014

ron minnich [mailto:rminnich@gmail.com] wrote: ]This is really interesting information, thanks. ] ]This embedded USB stack problem actually impacts HPC applications. ]This type of periodic interference can cause big troubles when you ]have lots of nodes. ] ]Look for "the case of the missing supercomputer performance" for a ]classic paper. In that case, a 1/30 hz (i.e. lpd dropping out of ]select every 30 seconds on 2048 nodes) was worth a couple tens of ]millions of dollars of performance. ] ]I'm amazed that the embedded USB stack problems are WORSE, not better, ]than they were a few years back. The x86 world just keeps getting more ]backwards. I'm sorry to see the ARM V8 world trying to emulate it. ] ]ron I have seen concern about BIOS SMI overhead from server customers running certain applications. These customers do not want avoidable interruptions of even a few uS. Some server BIOS enable a periodic SMI for various server management uses. This never ending periodic SMI is not wanted by these customers. But I thought all USB related SMI activity ends after a legacy BIOS hands control to an operating system that supports USB. For pure UEFI, I don't believe the USB uses SMI at all. So it would seem like disabling USB in the operating system would be just as good as doing it in BIOS. If an OS that predates USB is used, SMI will continue in order to support legacy 60/64 emulation. In this case, the easiest solution might be to set the global SMI mask in the south bridge, assuming this is the only source of SMI. Thanks, Scott On Tue, Aug 26, 2014 at 3:14 PM, Антон Кочков <anton.kochkov(a)gmail.com> wrote: > Hello, > > Just checked some binaries - PEI USB driver is loading anyway, no > checking for any setup option, so I guess it will be very hard even > with the unpacking UEFI image and removing these drivers. Also in most > UEFI systems big part of USB driver working in SMM mode, so it will be > hard to patch this code on the fly. > Best regards, > Anton Kochkov. > > > On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> Hi Ron, >> >> Am 26.08.2014 00:22 schrieb ron minnich: >>> disabling the usb stack is the goal in this case. >> >> AFAIK it's called "USB keyboard support", "USB legacy support" or >> something similar in most BIOSes. This internally maps a USB keyboard to >> a virtual PS/2 keyboard and sometimes has quite a few issues. If that's >> what your friend meant, disabling it should be straightforward in the >> BIOS menu. >> However, if your friend is a victim of EFI, I fear he is beyond help >> except for trying coreboot. >> >> Regards, >> Carl-Daniel >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] for more working mainboards
by ron minnich Aug. 27, 2014

Aug. 27, 2014

On Wed, Aug 27, 2014 at 11:11 AM, <echelon(a)free.fr> wrote: > Hello Ron, > Could you be more speciffic about "what is not doable" today? (and why?) > Sorry to be annoying.. You are not being annoying at all. And I wish I could say more. Let me just say that some of the hardware bugs I saw were very complex, and very subtle, and only observable on some very expensive logic analyzers. The resolution of them required a lot of help from the vendors. They took lots of time with lots of engineers and resolved down, typically, to very small changes. I was left feeling that the small outfits that used to do hardware in the early days (I mean the 70s and 80s) could never make it in this new world. It's very expensive and very hard. I realize some might see the raspberry pi is a counterpoint, but I don't think it really is, because the level of complexity of that system is so much less. ron

1 0

Re: [coreboot] for more working mainboards
by Mike Aug. 27, 2014

Aug. 27, 2014

Sounds very good. Please clarify, you mean the Acer Chromebook 13? Thanks in advance. On 08/27/2014 12:34 PM, ron minnich wrote: > I was talking to a friend about this the other day. > > Back when I were a mere lad, one could buy chips and build boards with > CPUs that were every bit as good as what any company could sell you. I > interned at HP working with engineers on boards, and I saw both sides, > the company and the garage/basement. There was not a lot of > difference. I built boards with many different microprocessors, and > even designed DRAM controllers. It was doable. > > I got a chance to watch the very talented engineers in the chromebook > part of Google for two years.After a few months watching them fix > problems that were very subtle, I found myself realizing that the era > of the Apple ][ was gone for good. I just don't see how "we can build > our own mainboards" model gets you to high quality, fast, low power > boards. I'd love to be shown wrong. But this "we should start a > company" thing that has been appearing in this list for 15 years is > now less practical than it was in 2000. > > Sorry, I don't like it either. > > If you really want a high quality, blob-free, open platform, you're > probably best off with ARM, and a good choice is the new Acer 13: > coreboot, no blobs, and it's really fine hardware at least for me. > > ron >

1 0

for more working mainboards
by Mike Aug. 27, 2014

Aug. 27, 2014

treacherous computing, like amd trustzone... http://www.arm.com/products/processors/technologies/trustzone/index.php ... could spawn all over. We have to stop this by giving end users more purchasing choice. Someone suggested that fsf actually produce mainboards without it. Sounds like a plan. Is fsf up to it? Are they willing to sign NDAs? If not, then we should start a company to do the mainboards. Producing amd/intel/etc boards. The current coreboot code would be fully applicable, and the mainboards would ship with coreboot. At least, coreboot might disable trusted computing functionality. Agree?

4 4

Re : Re: for more working mainboards
by echelon＠free.fr Aug. 27, 2014

Aug. 27, 2014

Hello Ron, Could you be more speciffic about "what is not doable" today? (and why?) Sorry to be annoying.. Regards, Florentin ----- Mail d'origine ----- De: ron minnich <rminnich(a)gmail.com> À: Patrick Georgi <patrick(a)georgi-clan.de> Cc: coreboot <coreboot(a)coreboot.org> Envoyé: Wed, 27 Aug 2014 18:34:03 +0200 (CEST) Objet: Re: [coreboot] for more working mainboards .... I got a chance to watch the very talented engineers in the chromebook part of Google for two years.After a few months watching them fix problems that were very subtle, I found myself realizing that the era of the Apple ][ was gone for good... ....

1 0

Re: [coreboot] disabling bios usb stack
by ron minnich Aug. 27, 2014

Aug. 27, 2014

This is really interesting information, thanks. This embedded USB stack problem actually impacts HPC applications. This type of periodic interference can cause big troubles when you have lots of nodes. Look for "the case of the missing supercomputer performance" for a classic paper. In that case, a 1/30 hz (i.e. lpd dropping out of select every 30 seconds on 2048 nodes) was worth a couple tens of millions of dollars of performance. I'm amazed that the embedded USB stack problems are WORSE, not better, than they were a few years back. The x86 world just keeps getting more backwards. I'm sorry to see the ARM V8 world trying to emulate it. ron On Tue, Aug 26, 2014 at 3:14 PM, Антон Кочков <anton.kochkov(a)gmail.com> wrote: > Hello, > > Just checked some binaries - PEI USB driver is loading anyway, no > checking for any setup option, so I guess it will be very hard even > with the unpacking UEFI image and removing these drivers. Also in most > UEFI systems big part of USB driver working in SMM mode, so it will be > hard to patch this code on the fly. > Best regards, > Anton Kochkov. > > > On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: >> Hi Ron, >> >> Am 26.08.2014 00:22 schrieb ron minnich: >>> disabling the usb stack is the goal in this case. >> >> AFAIK it's called "USB keyboard support", "USB legacy support" or >> something similar in most BIOSes. This internally maps a USB keyboard to >> a virtual PS/2 keyboard and sometimes has quite a few issues. If that's >> what your friend meant, disabling it should be straightforward in the >> BIOS menu. >> However, if your friend is a victim of EFI, I fear he is beyond help >> except for trying coreboot. >> >> Regards, >> Carl-Daniel >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

apologies in advance for a question I may have asked
by ron minnich Aug. 27, 2014

Aug. 27, 2014

I need to set up qemu with a 64MiB ROM. I figure supporting EFI has made QEMU capable of such things, but if anyone has direct experience with this, please let me know. I tried it a few years back (2008) and it did not work at all ... I guess worst case I can make an NE2000 "device" with a giant ROM, but I'd prefer to just do it with a 64MiB device at top of 4GiB address space. TIA ron

1 0

Re: [coreboot] disabling bios usb stack
by Carl-Daniel Hailfinger Aug. 26, 2014

Aug. 26, 2014

Hi Ron, Am 26.08.2014 00:22 schrieb ron minnich: > disabling the usb stack is the goal in this case. AFAIK it's called "USB keyboard support", "USB legacy support" or something similar in most BIOSes. This internally maps a USB keyboard to a virtual PS/2 keyboard and sometimes has quite a few issues. If that's what your friend meant, disabling it should be straightforward in the BIOS menu. However, if your friend is a victim of EFI, I fear he is beyond help except for trying coreboot. Regards, Carl-Daniel

2 1