coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] ASUS P2-99 with P2B config
by Keith Hui 29 Oct '17

29 Oct '17

Hi Branden, First, welcome and thanks for helping out with my work! > I wasn't planning on posting unless I could actually contribute > something, but since Keith Hui posted last month about his work on > CBMEM for 440BX and ACPI, I figured I should do some proper testing > and at least post if it worked out. There are certainly something you can contribute, which I'll get to in a moment. > I'm running coreboot on a ASUS P2-99 board with the config copied > straight from P2B. It's not perfect, but it is stable and I haven't > found anything that doesn't work that did with the original firmware. > > Testing I did over the past week: > > 1. Actually made a seperate P2-99 config, I'd been using vanilla P2B > with no renaming for a few months on it. I'd like you to pose your config on the list, so I can see how much different P2-99 is from P2B and if a new mainboard is warranted. Very long ago, I once got a P2-99 by way of a computer discarded by a friend of my father. I later traded it for a P3B-F that I still have today. I remember it uses a 440ZX northbridge, essentially a low-spec BX (2 slots, 512MB max, 4 PCI slots). What I don't remember is the super I/O chip it uses. But from what you wrote, you can run a mostly unmodified P2B build on it, so no new northbridge support should be necessary. > 3. Setup a serial console - seems to work fine. I was using I > different board for flashing anyway, since flashrom doesn't know the > board enable and the asus flasher only works on with original firmware > to find the board enable - it can flash coreboot though if you use the > right flag to tell it to flash the whole rom. As far as I know in this family of boards only P3B-F needs a board enable. Try this flashrom command on the board: # flashrom -p internal and see if a chip is detected. You need to get a i386/i686 build of flashrom to the board. Do you see a chip labelled AS99127F on your board? You may be able to use the flashrom trick for P3B-F [1] to enable internal flashing. > 4. Tried Keith Hui's ACPI patches > (https://review.coreboot.org/c/22067/). It has no problem booting or > restarting, but linux complains about the acpi. Didn't really expect > it to work properly on a different board anyway. Is it complaining about a missing MBRS table? It's an incomplete stub in the P2B board. I'm going to remove that and just include all the motherboard resources it declares in the ASL. > As it stands now, all I've done is run it with a P2B config and not > verified if everything is working as it should, I barely have beginner > knowledge of C and nothing on low level x86 or acpi, so I can't > actually do anything but testing. I can't upload board status for it > since it's a P2-99 not P2B. I'm also still stuck with with using > another board and hot swapping chips to flash roms. I should probably > post on the flashrom list that the board I'm flashing with works as > well as see if anyone knows anything about the asus board enable (it's > getting pretty old). I think the next step is to boot a 100% unmodified P2B build. That should allow you to run board_status (as far as it is concerned you're booting a P2B, albeit on a P2-99 hardware), but to actually do it you need to set yourself up on Gerrit. > > The main reason I'm posting is to say I can test patches the patches > Keith Hui has been working on and post logs. I'd also be glad for any > other recommendations on what I can do to help with this system. > Thanks again! To recap, our next steps: Show us your P2-99 Kconfig. Boot test an unmodified P2B build. Get Gerrit access for yourself so you can run board_status on it. Worse come to worst, I'll submit a asus/p2-99 patch for you. Check if you really need a board enable for flashrom. I'll submit a patch to move P2B to EARLY_CBMEM_INIT. Boot test it as soon as you can, since this is required to keep this board in tree past the real-soon-now 4.7 release. Then I'll update the ACPI patch for P2B (needs more restructuring based on feedbacks I received). It should not complain about missing stuff anymore. We'll go from there. If you need help pulling in a patch, I'll see how/if I can help. Keith [1] https://www.coreboot.org/Board:asus/p3b-f

1 0

Re: [coreboot] a blast from the past
by ron minnich 28 Oct '17

28 Oct '17

It's weird how this issue never went away. I had forgotten ever giving that talk. And yet everything it says is current 12 years later ... On Sat, Oct 28, 2017 at 8:39 AM Alberto Bursi <alberto.bursi(a)outlook.it> wrote: > > > On 10/28/2017 03:27 PM, ron minnich wrote: > > 2005, los alamos, a talk on EFI I had forgotten I had done. > > https://www.coreboot.org/images/d/d1/Openefi.pdf > > relevant to the current era. > > > > Sounds like the evil master plan behind your NERF project. > https://trmm.net/NERF > > Good luck with it, we really need this. > > -Alberto > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

minor wiki correction
by szbnwer＠gmail.com 28 Oct '17

28 Oct '17

hi all! ive just read a bit of wiki. as i started to follow the rabbits hole with libreboot, i've just found gluglug here: https://www.coreboot.org/Products the link works, it redirects to minifree, but a small correction would be good for it, and there can still be a "(formerly gluglug)" note after a minifree header for those who are already familiar with that name but didnt follow the change. ps: im feeling bad about myself, i remember that previously said that its so hard for newcomers to follow up a lotsa things, but now ive seen kinda much everything in the wiki that ive missed previously :D and all the bests for everyone around! :)

1 0

Re: [coreboot] a blast from the past
by Alberto Bursi 28 Oct '17

28 Oct '17

On 10/28/2017 03:27 PM, ron minnich wrote: 2005, los alamos, a talk on EFI I had forgotten I had done. https://www.coreboot.org/images/d/d1/Openefi.pdf relevant to the current era. Sounds like the evil master plan behind your NERF project. https://trmm.net/NERF Good luck with it, we really need this. -Alberto

1 0

riscv talk
by ron minnich 28 Oct '17

28 Oct '17

https://www.youtube.com/watch?v=HHABypJWMYk from andrew waterman, a good overview.

1 0

Re: [coreboot] a blast from the past
by Trammell Hudson 28 Oct '17

28 Oct '17

On Sat, Oct 28, 2017 at 01:27:17PM +0000, ron minnich wrote: > 2005, los alamos, a talk on EFI I had forgotten I had done. > https://www.coreboot.org/images/d/d1/Openefi.pdf > relevant to the current era. I believe you could give that talk today with almost zero changes... Jethro Beekman's efiperun, which "is to EFI as Wine is to Windows", is a possible way to addresss your comment that Linux-as-BIOS should "Get EFI emulation working under Linux": https://github.com/jethrogb/uefireverse/tree/master/efiperun -- Trammell

1 0

a blast from the past
by ron minnich 28 Oct '17

28 Oct '17

2005, los alamos, a talk on EFI I had forgotten I had done. https://www.coreboot.org/images/d/d1/Openefi.pdf relevant to the current era.

1 0

compulab_ltd/intense-pc: new Ivy Bridge board
by Hal Martin 28 Oct '17

28 Oct '17

Hello all, This is my first time working with coreboot. I've read the documentation, but I will probably make many noob mistakes. Sorry in advance! I've used autoport to create a new port for the CompuLab Intense PC (also sold as the "MintBox 2"). I've flashed the resulting coreboot.rom (including extracted VGA BIOS, ME, GbE, and IFD regions from the vendor firmware) and I can boot from USB as well as the main SATA HDD to Linux. Further testing details are included in my commit message. I would really appreciate it if someone could review my changes and provide feedback. For example, I have no idea about GPIO settings, or USB over current pins, and probably many more things to be corrected. I've also added a new Intel socket: FCBGA1023. There's no difference from other Sandy/Ivy Bridge sockets, but I thought it would be helpful to differentiate this socket from others (e.g. rPGA989). There are two changes to add this board: https://review.coreboot.org/#/c/22209/ : Add support for Intel FCBGA1023 socket https://review.coreboot.org/#/c/22210/ : mainboard/compulab_ltd support Thanks, Hal

1 0

X230 coreboot potential issues?
by Hans Fritz 27 Oct '17

27 Oct '17

Hi, I installed coreboot on my X230, it works very well except for these two things: When the screen goes to sleep and I move the mouse to wake it up, it wakes up at full brightness regardless of what the setting was before it went to sleep. If I press the button to lower or increase brightness, it switches back to what it was before sleeping. This didn't happen with the same Linux install but on the stock BIOS. The Fn key used to wake up the computer, but it doesn't anymore. Most Fn key combinations still work, except for Fn+F3 (lock screen). This was fine with the same Ubuntu install and the stock BIOS. Any thoughts? Are these issues with coreboot? Should I file an issue somewhere? Thanks!

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Zoran Stojsavljevic 27 Oct '17

27 Oct '17

I'll try (boldly, unfortunately) to help here... I really admire Kostja's tremendous fight for The Solution of this problem (for The Truth)! Since I see/read: GOOGLE and INTEL professionals are basically nowhere with the assessment of this problem (on this list)?! Why it is so, my dear friends??? One million $$ USD question!? Conscious question (my best guess)??? _______ Here is something out of deepness of my mind... As I recall! When HSW enters S3, its system context is retained in DRAM, so components not critical for state retention/waking up the host are turned off. One of the systems powered on in S3 is an USB system... As well as RTC system. And, after all, searching on these Realities, further down on the open net, here are some useful info: https://www.intel.com/content/dam/www/public/us/en/ documents/datasheets/4th-gen-core-family-mobile-m-h-processor-lines-vol-1- datasheet.pdf (Chapter 4.0 Power Management) I hope this can help... Somehow [*this time without attachment, since Coreboot mailer blocked me*] Zoran On Fri, Oct 27, 2017 at 7:09 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > I'll try (boldly, unfortunately) to help here... I really admire Kostja's > tremendous fight for The Solution of this problem (for The Truth)! > > Since I see/read: GOOGLE and INTEL professionals are basically nowhere > with the assessment of this problem (on this list)?! > > Why it is so, my dear friends??? One million $$ USD question!? Conscious > question (my best guess)??? > _______ > > Here is something out of deepness of my mind... As I recall! > > When HSW enters S3, its system context is retained in DRAM, so components > not critical for state retention/waking up the host are turned off. > One of the systems powered on in S3 is an USB system... As well as RTC > system. > > And, after all, searching on these Realities, further down on the open > net, here are some useful info: > https://www.intel.com/content/dam/www/public/us/en/ > documents/datasheets/4th-gen-core-family-mobile-m-h-processor-lines-vol-1- > datasheet.pdf > > (Chapter 4.0 Power Management) > > I hope this can help... Somehow! > > Zoran > > On Fri, Oct 27, 2017 at 2:14 PM, Аладышев Константин <aladyshev(a)nicevt.ru> > wrote: > >> Ok, I’ve found one more solution: don’t generate ACPI C-state tables. >> >> In "devicetree.cb" replace all C-states registers with 0, indicating C0 >> state. >> register "c1_battery" = "0" #"2" # >> ACPI(C1) = MWAIT(C1E) >> register "c2_battery" = "0" #"3" # >> ACPI(C2) = MWAIT(C3) >> register "c3_battery" = "0" #"9" # >> ACPI(C3) = MWAIT(C7S) >> >> register "c1_acpower" = "0" #"2" # >> ACPI(C1) = MWAIT(C1E) >> register "c2_acpower" = "0" #"3" # >> ACPI(C2) = MWAIT(C3) >> register "c3_acpower" = "0" #"9" # >> ACPI(C3) = MWAIT(C7S) >> >> After this change coreboot wouldn't generate _CST tables for ACPI >> C-states. >> >> Original BIOSes of two Haswell motherboards that I have, don’t generate >> _CST tables, so maybe it is not so bad. >> >> But I don’t quite understand why even without those tables "cpupower >> idle-info" and "cpupower monitor -m Idle_Stats" shows that CPU enters and >> exits all supported C-states. Btw, Haswell ULT has a lot of C-states: C0, >> C1, C1E, C2E, C3, C6, C7, C8, C9, C10. >> >> There are a lot of MSRs to control C-states + two alternative interfaces >> in ACPI (_CST and FADT), so it is quite hard for me to check if all of it >> is done correctly. >> >> State C3 and lower flush core caches, so maybe this is the reason why >> commit about EHCI command solves my issue. >> >> Also I've found interesting part in Haswell BWG: >> " >> Idle Duration Reporting is the capability for devices to communicate to >> the processor >> about their planned period of activity or idleness. Based on when the >> device would next >> interrupt the core, the PCU can place the core in an appropriate idle >> state. >> • On 4th Generation Intel® Core™ processors, cores are expected to report >> their Idle >> Duration time via the respective APIC timers. Since 4th Generation Intel® >> Core™ >> processors support Always running APIC timer (ARAT), the PCU will save >> this data >> when cores are in a deep sleep state and use the closest expiring timer >> value as the >> Device Idle duration. >> " >> >> So, maybe without APIC-timer cores can't report their activity/idleness >> time and C-states are not supported?? That is why boot with "noapictimer" >> doesn't have problems. >> >> Or maybe all problems are from wrong APIC timer. What do you think? What >> part of ACPI code is responsible for APIC timer setting? >> >> >> One more interesting observation: >> >> " >> On previous processors, the chipset was responsible for actually changing >> the >> processor C-state seen by the package. On 4th Generation Intel® Core™ >> processors, >> this logic moves to the System Agent, and the chipset is no longer >> responsible for >> driving processor package C-state transitions. >> " >> >> Can it be that mrc.bin (System Agent blob) just doesn't configured for >> C-states? >> >> >> And at the end I want to notice, that according to BWG BIOS should expose >> different C-states tables to different OSes by reading _PDC method and >> coreboot doesn't do it at all. >> >> >> P.S.: This issue was also responsible for USB stuck in Windows 7. So this >> problem is seems more important than support of some old Linux kernels. >> >> >> From: Аладышев Константин [mailto:aladyshev@nicevt.ru] >> Sent: Thursday, October 19, 2017 5:57 PM >> To: 'ron minnich'; 'Julius Werner' >> Cc: 'Coreboot' >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> No, unfortunately this option by itself doesn’t help. >> >> I guess my minimal hammer is ‘noapictimer’ >> >> But I wonder how these 3 boot parameters (‘noapictimer’ ‘nolapic’ and >> ‘acpi=off’) separately help to solve my issue. >> >> What part is wrong in ACPI and correct in MP-table? Maybe the problem is >> in ACPI MADT table? But it doesn’t really have much info that can be wrong. >> The one strangeness I found compared to original BIOS is mapping between >> ProcID and APIC ID in lapic entries. >> >> Coreboot has straightforward: 0-0, 1-1, 2-2, 3-3. >> But original BIOS has: 1-0, 2-2, 3-1, 4-3 >> >> I wonder if it means something? >> >> >> From: ron minnich [mailto:rminnich@gmail.com] >> Sent: Thursday, October 19, 2017 5:29 PM >> To: Аладышев Константин; Julius Werner >> Cc: Coreboot >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> we had a similar problem and we set >> pci=nocrs >> >> which means 'ignore what ACPI tells you and probe it again" >> >> It's much less of a big hammer than 'acpi=off' :-) >> >> On Thu, Oct 19, 2017 at 7:22 AM Аладышев Константин <aladyshev(a)nicevt.ru> >> wrote: >> I've found one more parameter that helps me boot without USB problem: >> 'noapictimer' >> >> >> -----Original Message----- >> From: Аладышев Константин [mailto:aladyshev@nicevt.ru] >> Sent: Wednesday, October 18, 2017 3:58 PM >> To: 'Julius Werner' >> Cc: 'Coreboot' >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> Ok, I've done some investigations about what can be the source of my >> problem: >> >> 1) last value of COMMAND register from BIOS I've dumped all EHCI >> registers (pci and memory) at the beginning of linux kernel EHCI >> initialization. And to my surprise pretty all memory registers in original >> BIOS look like almost uninitialized compared to my coreboot+seabios image. >> I don't really know how to work with EHCI controller, but seabios do it >> through periodic and async schedule and their enable bits (in COMMAND >> register from commit!) aren't active in original BIOS. I've tried to >> disable ehci initialization in seabios and after that registers dump >> started to look almost the same, compared to original bios, but it didn't >> solve my issue. Also without them USB doesn't work in grub. So it doesn't >> seem like BIOS last value of COMMAND register really matter. >> >> 2) SMI >> There are special registers for EHCI controller SMIs in its pci config >> space: >> -USB EHCI Legacy Support Extended >> -Intel Specific USB 2.0 SMI >> But in both of them SMIs are disabled as in coreboot+seabios image as in >> original bios. >> >> 3) ACPI >> In original BIOS ACPI doesn't do anything to EHCI COMMAND register from >> commit. It doesn't have a name for it or declare it in some region. Anyway >> I've copied almost all asl EHCI controller code, but it didn't help. >> >> BUT! I've provided MP-table and PIRQ table to coreboot and I can say that >> the problem disappears when I boot with 'acpi=off' parameter! >> Also it disappears when I boot with 'nolapic' parameter >> >> What do they have in common?? >> >> >> >> >> -----Original Message----- >> From: jwerner(a)google.com [mailto:jwerner@google.com] On Behalf Of Julius >> Werner >> Sent: Tuesday, October 10, 2017 5:56 AM >> To: Аладышев Константин >> Cc: Coreboot >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> > And now I'm kinda stuck. The effect of this commit doesn't seem to >> > interface with bios for me. So how does original IBASE/DFI bios can >> > overcome code error before this commit? >> > >> > What can be the source of my problem? What should I investigate more >> > precise based on result that I've got? >> >> My gut feeling would be to blame ACPI. The Linux patch is about caching a >> host controller register in the kernel, and in some cases (e.g. >> ehci_reset()), the patch re-reads the cached version from the hardware >> whereas the previous code didn't. If some BIOS ACPI mucks with that >> register, it's possible that this got the kernel's cached copy out of sync >> before this patch, but with the patch the kernel will re-read it from the >> hardware at the right time. Maybe only coreboot's ACPI routines touch the >> register in that path, or maybe the vendor BIOS' routines were more careful >> to restore the original state afterwards. >> >> Besides ACPI this could also be in SMM code, I guess (especially if the >> problem occurs around system suspend/resume, although it sounds like it >> doesn't for you). >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >

1 0

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 October 2017