coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

Re: [coreboot] Need help implementing romstage CBMEM
by Keith Hui 31 Aug '17

31 Aug '17

Oops, I've attached the boot log of a previous failed attempt. This boot log should be the correct one. On Thu, Aug 31, 2017 at 1:29 PM, Keith Hui <buurin(a)gmail.com> wrote: > On Wed, Aug 30, 2017 at 6:49 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >> On Wed, Aug 30, 2017 at 11:39 PM, Keith Hui <buurin(a)gmail.com> wrote: >>> Hi guys, >>> >>> I'm still hard at work over the venerable (even "almighty" at the >>> time) 440BX and Slot 1 boards. >>> >>> [1] https://review.coreboot.org/c/20977/ >>> >>> And now I'm stuck and thoroughly confused. >>> >>> My current state is: >>> 1. cbmem_initialize_empty() failed to even start allocating the root >>> CBMEM entry. No indication why. I tried tracing the code path in the >>> sources and still could not find out where exactly it failed. With >>> enough fiddling I did get it to complain the way Aaron expected [1]. >> >> Please update your work in gerrit, showing all the actual code changes >> you try to boot with. This includes changes under mainboard/. >> >>> 2. Using the common Intel CPU cache_as_ram.inc, I can get through >>> mainboard romstage and memory init. If I just return a fixed >>> CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in >>> cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and >>> then nothing. >> >> All that setup_stack_and_mtrrs() is not really required for >> EARLY_CBMEM_INIT, leave all that as followup work. Use unmodified >> car/romstage_legacy.c and car/cache_as_ram.inc with that >> DCACHE_RAM_BASE fixed. >> >> Disable CBMEM console and timestamps for the time being, as those eat >> a lot of your CAR allocation. Those may have smashed your stack in CAR >> to the extent of breaking raminit. >> >>> 3. Porting the postcar frame assembly from >>> cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere >>> before loading ramstage and after >> >> Push your modified source to gerrit if you want comments on that. >> >>> 4. If I try to run this build under QEMU, it fails with "Trying to >>> execute code outside RAM or ROM at 0x000a0000" in 440BX RAM init code >>> after dumping the "before" northbridge config, so I can't correctly >>> debug it this way either. >> >> Just forget about using QEMU for the task at hand. >> >> Kyösti > > Thanks for the tips Kyösti. Nothing like hearing it from the source. :) > > I've updated gerrit again following your tips. This update actually > boots! Boot log attached. > > For cache_as_ram.inc I just dropped CacheBase/CacheSize and have it > use the Kconfig settings directly. I also increased the CAR size to > 8k. > > Q1: Would this qualify as cbmem in romstage? > > Set up stack and MTRRs in cpu/intel/slot_1 > cbmem_top() and associated top of RAM calculations go to nb/intel/i440bx. > > Q2: Are these the right places for these codes? > All Slot 1 boards currently in tree use 440BX and much of them seem > unmaintained. I only have 3 of them (-LS, P3B-F, -DS) and I don't have > a second matching P3 CPU to test the DS. So I want to see if I can > initialize CBMEM in cpu/intel/slot_1, lest work wasted with all those > other boards getting dropped past 4.8?

1 0

Re: [coreboot] Need help implementing romstage CBMEM
by Keith Hui 31 Aug '17

31 Aug '17

On Wed, Aug 30, 2017 at 6:49 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Wed, Aug 30, 2017 at 11:39 PM, Keith Hui <buurin(a)gmail.com> wrote: >> Hi guys, >> >> I'm still hard at work over the venerable (even "almighty" at the >> time) 440BX and Slot 1 boards. >> >> [1] https://review.coreboot.org/c/20977/ >> >> And now I'm stuck and thoroughly confused. >> >> My current state is: >> 1. cbmem_initialize_empty() failed to even start allocating the root >> CBMEM entry. No indication why. I tried tracing the code path in the >> sources and still could not find out where exactly it failed. With >> enough fiddling I did get it to complain the way Aaron expected [1]. > > Please update your work in gerrit, showing all the actual code changes > you try to boot with. This includes changes under mainboard/. > >> 2. Using the common Intel CPU cache_as_ram.inc, I can get through >> mainboard romstage and memory init. If I just return a fixed >> CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in >> cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and >> then nothing. > > All that setup_stack_and_mtrrs() is not really required for > EARLY_CBMEM_INIT, leave all that as followup work. Use unmodified > car/romstage_legacy.c and car/cache_as_ram.inc with that > DCACHE_RAM_BASE fixed. > > Disable CBMEM console and timestamps for the time being, as those eat > a lot of your CAR allocation. Those may have smashed your stack in CAR > to the extent of breaking raminit. > >> 3. Porting the postcar frame assembly from >> cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere >> before loading ramstage and after > > Push your modified source to gerrit if you want comments on that. > >> 4. If I try to run this build under QEMU, it fails with "Trying to >> execute code outside RAM or ROM at 0x000a0000" in 440BX RAM init code >> after dumping the "before" northbridge config, so I can't correctly >> debug it this way either. > > Just forget about using QEMU for the task at hand. > > Kyösti Thanks for the tips Kyösti. Nothing like hearing it from the source. :) I've updated gerrit again following your tips. This update actually boots! Boot log attached. For cache_as_ram.inc I just dropped CacheBase/CacheSize and have it use the Kconfig settings directly. I also increased the CAR size to 8k. Q1: Would this qualify as cbmem in romstage? Set up stack and MTRRs in cpu/intel/slot_1 cbmem_top() and associated top of RAM calculations go to nb/intel/i440bx. Q2: Are these the right places for these codes? All Slot 1 boards currently in tree use 440BX and much of them seem unmaintained. I only have 3 of them (-LS, P3B-F, -DS) and I don't have a second matching P3 CPU to test the DS. So I want to see if I can initialize CBMEM in cpu/intel/slot_1, lest work wasted with all those other boards getting dropped past 4.8?

1 0

ECS 651-M V1.0 is supported?
by Olaf HB 31 Aug '17

31 Aug '17

Hi. I would like to know if the ECS 651-M V1.0 motherboard is supported in coreboot or could it be supported? Specs: Socket 478 for latest Intel Pentium 4 / Celeron processor SiS® 650GX B0 & 962L North Bridge: SiS® 650GX B0 South Bridge: SiS® 962L SYSTEM BIOS Award BIOS with 2Mb Flash ROM (soldered to board) Supports Plug and Play 1.0A, APM 1.2, Multi Boot, DMI Supports ACPI revision 1.0 specification Super I/O chip: ITE it8705f Link to product: http://www.ecs.com.tw/ECSWebSite/Product/Product_SPEC.aspx?DetailID=362 &CategoryID=1&DetailName=Feature&MenuID=24&LanID=0 lspci and flashrom output is attached in email. Greetings.

1 0

Re: [coreboot] Need help implementing romstage CBMEM
by Kyösti Mälkki 31 Aug '17

31 Aug '17

On Wed, Aug 30, 2017 at 11:39 PM, Keith Hui <buurin(a)gmail.com> wrote: > Hi guys, > > I'm still hard at work over the venerable (even "almighty" at the > time) 440BX and Slot 1 boards. > > [1] https://review.coreboot.org/c/20977/ > > And now I'm stuck and thoroughly confused. > > My current state is: > 1. cbmem_initialize_empty() failed to even start allocating the root > CBMEM entry. No indication why. I tried tracing the code path in the > sources and still could not find out where exactly it failed. With > enough fiddling I did get it to complain the way Aaron expected [1]. Please update your work in gerrit, showing all the actual code changes you try to boot with. This includes changes under mainboard/. > 2. Using the common Intel CPU cache_as_ram.inc, I can get through > mainboard romstage and memory init. If I just return a fixed > CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in > cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and > then nothing. All that setup_stack_and_mtrrs() is not really required for EARLY_CBMEM_INIT, leave all that as followup work. Use unmodified car/romstage_legacy.c and car/cache_as_ram.inc with that DCACHE_RAM_BASE fixed. Disable CBMEM console and timestamps for the time being, as those eat a lot of your CAR allocation. Those may have smashed your stack in CAR to the extent of breaking raminit. > 3. Porting the postcar frame assembly from > cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere > before loading ramstage and after Push your modified source to gerrit if you want comments on that. > 4. If I try to run this build under QEMU, it fails with "Trying to > execute code outside RAM or ROM at 0x000a0000" in 440BX RAM init code > after dumping the "before" northbridge config, so I can't correctly > debug it this way either. Just forget about using QEMU for the task at hand. Kyösti

1 0

Need help implementing romstage CBMEM
by Keith Hui 30 Aug '17

30 Aug '17

Hi guys, I'm still hard at work over the venerable (even "almighty" at the time) 440BX and Slot 1 boards. [1] https://review.coreboot.org/c/20977/ And now I'm stuck and thoroughly confused. My current state is: 1. cbmem_initialize_empty() failed to even start allocating the root CBMEM entry. No indication why. I tried tracing the code path in the sources and still could not find out where exactly it failed. With enough fiddling I did get it to complain the way Aaron expected [1]. 2. Using the common Intel CPU cache_as_ram.inc, I can get through mainboard romstage and memory init. If I just return a fixed CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and then nothing. 3. Porting the postcar frame assembly from cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere before loading ramstage and after 4. If I try to run this build under QEMU, it fails with "Trying to execute code outside RAM or ROM at 0x000a0000" in 440BX RAM init code after dumping the "before" northbridge config, so I can't correctly debug it this way either. I think there's still not clear enough description on how this dynamic CBMEM allocation works. Below is my take and I'll stand readily to be corrected: 1. Reset vector -> protected mode -> southbridge bootblock init for ROM -> bootblock walks CBFS to find romstage. 2. CAR setup in cpu/intel/car/cache_as_ram.inc 3. romstage_main() -> sets up a stack guard -> mainboard_romstage_entry() -> check for overunning of said stack guard 4. romstage calls cbmem_initialize_empty() 5. Somewhere along the cbmem_initialize() path cbmem_top() is called to find out where top of RAM is. It is supposed to allocate memory so that it grows down from here. 6. setup_stack_and_mtrrs() -> allocates a 20KB postcar stack on CBMEM and adds MTRR settings as appropriate. These gets pushed onto the postcar stack in order of popping: maximum number of supported variable MTRRs <- bottom of stack number of actual used MTRRs MTRR 0 base, low 32 bits MTRR 0 base, high 32 bits MTRR 0 mask, low 32 bits MTRR 0 mask, high 32 bits ... And this stack should be in RAM, supposedly in an area allocated within CBMEM. 7. This postcar stack pointer is returned via romstage_main(). It gets loaded into %esp, effectively switching the code into a RAM stack with all the MTRRs info on it. 8. Tear down CAR. 9. Wipes all the MTRRs. 10. MTRR values are popped off the stack and loaded into the variable MTRRs. 11. Now the CPU should be at the top of the allocated RAM stack and can move on to load the ramstage. The sources say for step 5 "the number of entries depends on the size between down-aligned (by 4k) version and the actual top of memory. I thought cbmem_top() should return the actual bytes of available memory and is already aligned and I'd end up with room for zero entries? And if I just return the actual top of memory cbmem_top() for use a the romstage stack, would it not overwrite the cbmem area? Also how much room is there to consolidate the CAR setup and teardown code and/or move more of it into C? All the Slot 1 CPUs are in the P6 family and have 16KB L1 data cache that is 4-way set associative. Can I use a full 16K range for CAR or I can only use 4K (16K/4) of it? cache_as_ram.inc use a fixed MTRR that tops out at address 0xD0000 while cache_as_ram_ht.inc uses variable MTRR 0 for this range. Variable MTRR 1 is used in both to cache the ROM. But when I tried to port the latter approach over the code dies doing it. Some Slot 1 CPUs have a very complicated L2 enable code which is better left where it is so I'd like to limit myself to L1 cache at this stage. Sorry if I am not making sense, because this is not making sense to me either, so any help is appreciated.

1 0

Re: [coreboot] Libre KCMA-D8's are going for around $260 on newegg
by Gregg Levine 30 Aug '17

30 Aug '17

Hello! Suffice to say, I've been elsewhere as well. If anything, I only bought one thing from that firm. The comments on that page you brought us is rather critical of that decision. For my part I also buy the majority of my computer directed electronics at Micro Center,(A US based firm with many stores in many states.). and almost everything else from two other firms, three if I'd count Adafruit. For those of us in the US the board prices at Micro Center happen to be reasonable. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Wed, Aug 30, 2017 at 9:14 AM, Rene Shuster <rene.shuster(a)bcsemail.org> wrote: > I must be living under a rock; totally missed that story: > https://www.techpowerup.com/226777/newegg-now-owned-by-chinese-company > (2016-09) > > On Wed, Aug 30, 2017 at 1:11 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> >> NOTE: I have no idea as to how trustworthy these companies are. >> >> >> http://www.officespecialties.com/asus_computer_international_kcma_d8_server… >> Ah even better, $250 and now one doesn't have to support a chinese owned >> newegg. >> >> http://www.unitedoffice.com/pn/KCMAD8/Asus_46/ >> $270 another option >> >> >> http://www.compsource.com/pn/KCMAD8/Asus-46/KcmaD8-Server-Motherboard-KCMAD… >> $260 >> >>

1 0

KGPE-D16 BMC port
by Timothy Pearson 30 Aug '17

30 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We are pleased to announce that the OpenBMC port for the KGPE-D16 has reached the first release stage! https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php While it has inherited some of the rough edges of its Facebook predecessor in terms of its external interfaces, this OpenBMC port is fully functional for system control and thermal management. We have tested both ASMB4 and ASMB5 modules with the KGPE-D16 and both function the same, so feel free to purchase whichever one is more readily available in your location. The weakest part of the port at this time is IPMI (provided by ipmid). Only the chassis status command really works at this point, but all of the "plumbing" is present that is required for both external (network-based) and internal (LPC KCS-based) communication; the ipmitool utility does have the ability to communicate with the BMC as of this release. You may need to modprobe ipmi_si and ipmi_devintf before ipmitool will function, depending on your distribution's default settings. One final note: if you enable OpenBMC, don't try to run fan-control under Linux. It will cause the hardware control chip on the shared I2C bus to malfunction, and the BMC will detect this and shut the entire system down to protect it from overtemperature. No permanent harm will be done, but data loss is possible. The best thing to do is to make sure the w83795 module is not loaded on the host. Also, since I think this was buried in another Email thread, I'd like to mention again that we are offering a 75% discount to the coreboot community on the REACTS system [1] in an effort to get higher test coverage. Use this promotional code when checking out to apply the discount: COREBOOTREACTS17 Let me know what you think of the OpenBMC system. We're considering allowing bugs to be tracked on GitHub; is this something the community wants to see or would a separate Bugzilla type install be preferred? We want to provide the infrastructure needed for the community to start working with and enhancing this port, so suggestions and comments are welcome! [1] https://www.raptorengineering.com/content/REACTS/intro.html - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZpbFQAAoJEK+E3vEXDOFbWGsH/1WN4KMm1GCYUVdcj2wdD1XF EkZ5H6Yu6p+8Fj+WkOaNsHb8xSFG5rqPPZC8ubT+tt4gcUqsgFzYLYDXACH6y4Yc RFoSHd7rXYB9uBG1uzZIhQovfL65a6Y5+LTuhL9CYNXP7iR64L44NjgD1HFv8BS7 ryJ+K/LE941uOin8GQshoFwJ/i88uOMpKunF5Ef+SnGr4VhE5OvUrulpo5iJ/62J Ia3v9zD9hTppGyi2MNydR7qy5kVrABHiq+6C2LiQtpfBx/GOwNevZbbvt+aswEnc jEItl/I6YBTAMyT4eGdc5LW+0H83sw8mwynK1DTzZXGGTKw/xvkun5UcvrvU4Q8= =dqp/ -----END PGP SIGNATURE-----

3 2

Libre KCMA-D8's are going for around $260 on newegg
by Taiidan＠gmx.com 30 Aug '17

30 Aug '17

This is a great chance to pick up one of the last and best owner controlled x86 boards for much less than the usual price ($350) and MSRP ($315). Compatable with Qubes 4.0! Supports IOMMU for graphics! (so you can play video games in a VM) CPU's cost around $10-50 and 16GB DDR3 ECC RAM is $30 Recommended Accessories: ASMB4-iKVM (BMC Module, required for the upcoming libre OpenBMC port for KGPE-D16/KCMA-D8 the asus boards) TPM (Coreboot supports an owner controlled core root of trust which is more secure than otherwise) Note: 128GB RAM Max You will have to get a graphics card if you want decent video, the onboard chip only supports 1280x768 and is quite slow - AMD is reccomended for better virtualization (see nvidia code 43 "bug" when you try to attach their cards to a VM) and linux drivers that are almost open source and don't suck unlike nvidia 43xx CPU's require microcode updates for secure operation Reccomended CPU's: 4284 (Works securely without microcode updates) 4365EE (40W, for a low power build) 4386 (equivalent to AMD FX 8310)

2 2

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Timothy Pearson 30 Aug '17

30 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2017 06:10 AM, Rene Shuster wrote: > Wow. My favorite part is where the NSA itself basically admits that the ME can't be trusted! I wonder if they are looking at other architectures or if this HAP bit was enough for their needs? - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZpa8rAAoJEK+E3vEXDOFbBv4H/RmRr8k9PFutCi9XqEamcLJy UIrLs+XBH92AxWVQVSQH7LL+bFYCyANNkYHYpiaZ1V4lxuoDM0WVi3HdfDpCqTPV MLklowZVrQAGPyNIW05agVh+GYTSoCWZ0fGk8IUo8j57PN/J0KWMvGjxnXQ9KFmv I0wuFs0VrIB8IVXGf9vCw73jbr+BOW6jlTyohlk8cYIGC/i0YT1zwO88DmG+i9Qg RqPXQ53eeSOv/JTo6NYgA8DP0JqNpbvqM+xI3irwZXw8FLg/ScPo+HNi7jl+i1yz evBkOoDvV3ACpybtf+tB+rVlKxNs0JBqhoM5UiY58kga2Lik6/CqHMrN7p7AM8s= =WzpR -----END PGP SIGNATURE-----

6 7

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 29 Aug '17

29 Aug '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1380036: Control flow issues (NO_EFFECT) /src/soc/intel/cannonlake/romstage/romstage.c: 80 in soc_memory_init_params() ________________________________________________________________________________________________________ *** CID 1380036: Control flow issues (NO_EFFECT) /src/soc/intel/cannonlake/romstage/romstage.c: 80 in soc_memory_init_params() 74 m_cfg->TsegSize = CONFIG_SMM_TSEG_SIZE; 75 m_cfg->IedSize = CONFIG_IED_REGION_SIZE; 76 m_cfg->SaGv = config->SaGv; 77 m_cfg->UserBd = BOARD_TYPE_ULT_ULX; 78 m_cfg->RMT = config->RMT; 79 >>> CID 1380036: Control flow issues (NO_EFFECT) >>> "i" is converted to an unsigned type because it's compared to an unsigned constant. 80 for (i = 0; i < ARRAY_SIZE(config->PcieRpEnable); i++) { 81 if (config->PcieRpEnable[i]) 82 mask |= (1 << i); 83 } 84 m_cfg->PcieRpEnableMask = mask; 85 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

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