[coreboot] Re: i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I tested https://review.coreboot.org/c/coreboot/+/59693/ nb/intel/i440bx: Use PARALLEL_MP patchset 6 on my p2-99 and it appears to work properly. The work around of disabling including the config in the rom to free up space wasn't enough with this patchset though, so I just disabled including microcode updates for now. I'm hoping the LTO and romstage sources inside the bootblock will make in it yet, since they both saved s[pace. I only attached a specific portion of the log, since it got rather long with spew set. Branden Waldner Initializing devices... CPU_CLUSTER: 0 init CPU: . Setting up local APIC 0x0 Initializing CPU #0 CPU: vendor Intel device 681 CPU: family 06, model 08, stepping 01 MTRR: Physical address space: 0x - 0x000a size 0x000a type 6 0x000a - 0x000c size 0x0002 type 0 0x000c - 0x2000 size 0x1ff4 type 6 0x2000 - 0x4000 size 0x2000 type 1 0x4000 - 0x0001 size 0xc000 type 0 MTRR: Fixed MSR 0x250 0x0606060606060606 MTRR: Fixed MSR 0x258 0x0606060606060606 MTRR: Fixed MSR 0x259 0x MTRR: Fixed MSR 0x268 0x0606060606060606 MTRR: Fixed MSR 0x269 0x0606060606060606 MTRR: Fixed MSR 0x26a 0x0606060606060606 MTRR: Fixed MSR 0x26b 0x0606060606060606 MTRR: Fixed MSR 0x26c 0x0606060606060606 MTRR: Fixed MSR 0x26d 0x0606060606060606 MTRR: Fixed MSR 0x26e 0x0606060606060606 MTRR: Fixed MSR 0x26f 0x0606060606060606 call enable_fixed_mtrr() CPU physical address size: 36 bits MTRR: default type WB/UC MTRR counts: 3/2. MTRR: UC selected as default type. MTRR: 0 base 0x mask 0x000fe000 type 6 MTRR: 1 base 0x2000 mask 0x000fe000 type 1 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled FMAP: area COREBOOT found @ 200 (261632 bytes) CBFS: 'cpu_microcode_blob.bin' not found. CPU #0 initialized On 11/30/21, Keith Hui wrote: > Hi guys, > > Just a heads-up. Soon after I confirmed the issue with Arthur's > patches (and he told us of his fix), I ran into major stability issues > with all my boards to the point I couldn't reliably boot any of them. > Granted they were sitting naked between a desk lamp and the power > supply so EMI could be an issue. I don't know, and I probably won't > find out for sure until next week when I can house them properly. > > Branden, I'll appreciate if you can confirm whether Arthur's SSE2 > workaround fix the issue. > > Thanks > Keith > > On Tue, 30 Nov 2021 at 15:15, Branden Waldner wrote: >> >> On 11/30/21, Keith Hui wrote: >> > I suffered an unexpected exception after applying the patch train. >> > Serial log at the end of this email. I probably could leave out >> > bootblock/romstage/postcar, but it's here for completeness. Next: >> > bisect. >> >> I had a similar result testing on my P2B. I'm working on recovering it >> and I was planning on trying a build with log level spew on the P2-99 >> since it is easy for me to recover with the way I have it setup right >> now. >> >> Branden Waldner > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi guys, Just a heads-up. Soon after I confirmed the issue with Arthur's patches (and he told us of his fix), I ran into major stability issues with all my boards to the point I couldn't reliably boot any of them. Granted they were sitting naked between a desk lamp and the power supply so EMI could be an issue. I don't know, and I probably won't find out for sure until next week when I can house them properly. Branden, I'll appreciate if you can confirm whether Arthur's SSE2 workaround fix the issue. Thanks Keith On Tue, 30 Nov 2021 at 15:15, Branden Waldner wrote: > > On 11/30/21, Keith Hui wrote: > > I suffered an unexpected exception after applying the patch train. > > Serial log at the end of this email. I probably could leave out > > bootblock/romstage/postcar, but it's here for completeness. Next: > > bisect. > > I had a similar result testing on my P2B. I'm working on recovering it > and I was planning on trying a build with log level spew on the P2-99 > since it is easy for me to recover with the way I have it setup right > now. > > Branden Waldner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #323] (New) thinkpad T60 expresscard support
Issue #323 has been reported by Michael Edelmann. Bug #323: thinkpad T60 expresscard support https://ticket.coreboot.org/issues/323 * Author: Michael Edelmann * Status: New * Priority: Normal * Assignee: * Category: board support * Target version: I was playing around with expresscard usb 3.0 adapters on a thinkpad T60 and noticed that coreboot breaks its functionality. i tested both the stock bios and coreboot revision b2e8bd83647f664260120fdfc7d07cba694dd89e, the logs listed under https://www.coreboot.org/Motherboard_Porting_Guide are included in the 'coreboot' and 'stock' directories. of course i had my card inserted when i took the logs lspci shows the card under the stock bios, it works fine. coreboot doesnt seem to do anything with it, its getting no power. the card i got, as seen in the attached image, has been known to work on GNU/Linux for other people out of the box, apparently not for coreboot. i'd be glad if coreboot supported expresscards for 2 additional USB ports, thanks for taking a look at it! ---Files card.jpg (41.1 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
On 11/30/21, Keith Hui wrote: > I suffered an unexpected exception after applying the patch train. > Serial log at the end of this email. I probably could leave out > bootblock/romstage/postcar, but it's here for completeness. Next: > bisect. I had a similar result testing on my P2B. I'm working on recovering it and I was planning on trying a build with log level spew on the P2-99 since it is easy for me to recover with the way I have it setup right now. Branden Waldner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Keith Thanks a lot for testing! It looks like the newer parallel mp code uses "mfence" which is probably not supported by your CPU. I updated the code to reflect that. I'd appreciate if you can test the latest version of https://review.coreboot.org/c/coreboot/+/59693/ Kind regards On Tue, Nov 30, 2021 at 8:13 PM Keith Hui wrote: > Hi everyone, > > Thanks for your efforts to keep a computing legend alive. :) > > I suffered an unexpected exception after applying the patch train. > Serial log at the end of this email. I probably could leave out > bootblock/romstage/postcar, but it's here for completeness. Next: > bisect. > > I do still have a P2B-DS on hand, but all my Pentium 3 CPUs are > singles, and Pentium III-S 1400MHz (the best CPU money can buy for > this board) are running ~$85 apiece on ebay. On the other hand, I > think one of my two P2B-LS may have died. > > (Branden - and a P3B-F board too. ;-) > > Meanwhile, I should have pushed harder to get P8Z77-M into the tree. > > Keith > > On Tue, 30 Nov 2021 at 05:32, Angel Pons wrote: > > > > Hi Branden, > > > > On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner > wrote: > > > > > > I wasn't really sure that I wanted to comment on this, but seeing as > > > how I have some of the affected boards I guess I should. > > > > Thank you very much. > > > > > Angel Pons wrote: > > > > Besides AMD AGESA boards, the other boards that need to be updated > are AOpen DXPL > > > > Plus-U (a dual-socket server board that uses Netburst Xeons, no > other board in the tree uses > > > > the same chipset code) and various Asus P2B boards (which support > Pentium 2/3 CPUs, these > > > > boards are older than me). Even though I only know two people who > still have some of these > > > > boards (and they don't have the same boards), they're still > supported because the code has > > > > been maintained so far. > > > > > > I am one of the two with Asus P2B boards, with Keith Hui being the > > > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > > > P2B-LS. > > > So far there have not been very many changes and Keith Hui and others > > > have worked on them, all I've done is test master and relevant patch > > > sets every once in a while. > > > I know I have not been uploading board_status results and I have not > > > gotten around to fixing the variant set up for the P2-99 so I'm not > > > uploading results that are uncertain about which board they are for. > > > Not really relevant, but I think it is pretty neat to be running > > > coreboot on boards older then some of the contributors. > > > > > > Mike Banon wrote: > > > > I am often build-testing my boards (didn't notice a > > > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, > but only because I've been > > > > re-using the previously built toolchains to save time). Also, I am > actively tech-supporting all the > > > > people who would like to build coreboot for AMD boards from this > list, even right now I am in an > > > > active message exchange with >10 people who are switching to these > boards to run coreboot > > > > on them - and any user may give back to the project one day. > > > > > > I actually have a few AMD boards and laptops that might be viable for > > > porting to, but I've never looked in to it much because of the state > > > support is in coreboot and the fact most of the hardware was actively > > > being used. > > > > > > Arthur Heymans wrote: > > > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also > includes the codepath for > > > > SMM_ASEG. This code is used to start APs and do some feature > programming on each AP, but > > > > also set up SMM. This has largely been superseded by PARALLEL_MP, > which should be able > > > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. > The reason for > > > > deprecation is that having 2 codepaths to do the virtually the same > increases maintenance > > > > burden on the community a lot, while also being rather confusing. > > > > > > > > A few things are lacking in PARALLEL_MP init: - Support for > !CONFIG_SMP on single core > > > > systems. It's likely easy to extend PARALLEL_MP or write some code > that just does CPU > > > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa > - 0xb) region. A > > > > POC showed that it's not that hard to do with PARALLEL_MP > > > > https://review.coreboot.org/c/coreboot/+/58700 > > > > > > I didn't even know that was a problem until now. I doubt there is much > > > I can do about it myself at this point in time, though I can try to > > > look through it I guess. > > > > Looks like Arthur has already implemented some changes to use > > PARALLEL_MP on i440bx. As of writing, the patches assume there's only > > one CPU (I already pointed out this is incorrect for boards with two > > CPU sockets/slots). I'd greatly appreciate if Keith and/or you could > > test them on actual hardware. The patches to apply, in order, are: > > > >
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi everyone, Thanks for your efforts to keep a computing legend alive. :) I suffered an unexpected exception after applying the patch train. Serial log at the end of this email. I probably could leave out bootblock/romstage/postcar, but it's here for completeness. Next: bisect. I do still have a P2B-DS on hand, but all my Pentium 3 CPUs are singles, and Pentium III-S 1400MHz (the best CPU money can buy for this board) are running ~$85 apiece on ebay. On the other hand, I think one of my two P2B-LS may have died. (Branden - and a P3B-F board too. ;-) Meanwhile, I should have pushed harder to get P8Z77-M into the tree. Keith On Tue, 30 Nov 2021 at 05:32, Angel Pons wrote: > > Hi Branden, > > On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote: > > > > I wasn't really sure that I wanted to comment on this, but seeing as > > how I have some of the affected boards I guess I should. > > Thank you very much. > > > Angel Pons wrote: > > > Besides AMD AGESA boards, the other boards that need to be updated are > > > AOpen DXPL > > > Plus-U (a dual-socket server board that uses Netburst Xeons, no other > > > board in the tree uses > > > the same chipset code) and various Asus P2B boards (which support Pentium > > > 2/3 CPUs, these > > > boards are older than me). Even though I only know two people who still > > > have some of these > > > boards (and they don't have the same boards), they're still supported > > > because the code has > > > been maintained so far. > > > > I am one of the two with Asus P2B boards, with Keith Hui being the > > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > > P2B-LS. > > So far there have not been very many changes and Keith Hui and others > > have worked on them, all I've done is test master and relevant patch > > sets every once in a while. > > I know I have not been uploading board_status results and I have not > > gotten around to fixing the variant set up for the P2-99 so I'm not > > uploading results that are uncertain about which board they are for. > > Not really relevant, but I think it is pretty neat to be running > > coreboot on boards older then some of the contributors. > > > > Mike Banon wrote: > > > I am often build-testing my boards (didn't notice a > > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but > > > only because I've been > > > re-using the previously built toolchains to save time). Also, I am > > > actively tech-supporting all the > > > people who would like to build coreboot for AMD boards from this list, > > > even right now I am in an > > > active message exchange with >10 people who are switching to these boards > > > to run coreboot > > > on them - and any user may give back to the project one day. > > > > I actually have a few AMD boards and laptops that might be viable for > > porting to, but I've never looked in to it much because of the state > > support is in coreboot and the fact most of the hardware was actively > > being used. > > > > Arthur Heymans wrote: > > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also > > > includes the codepath for > > > SMM_ASEG. This code is used to start APs and do some feature programming > > > on each AP, but > > > also set up SMM. This has largely been superseded by PARALLEL_MP, which > > > should be able > > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > > > reason for > > > deprecation is that having 2 codepaths to do the virtually the same > > > increases maintenance > > > burden on the community a lot, while also being rather confusing. > > > > > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP > > > on single core > > > systems. It's likely easy to extend PARALLEL_MP or write some code that > > > just does CPU > > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > > > 0xb) region. A > > > POC showed that it's not that hard to do with PARALLEL_MP > > > https://review.coreboot.org/c/coreboot/+/58700 > > > > I didn't even know that was a problem until now. I doubt there is much > > I can do about it myself at this point in time, though I can try to > > look through it I guess. > > Looks like Arthur has already implemented some changes to use > PARALLEL_MP on i440bx. As of writing, the patches assume there's only > one CPU (I already pointed out this is incorrect for boards with two > CPU sockets/slots). I'd greatly appreciate if Keith and/or you could > test them on actual hardware. The patches to apply, in order, are: > > https://review.coreboot.org/59694 > https://review.coreboot.org/59695 > https://review.coreboot.org/59692 > https://review.coreboot.org/59693 > > > Branden Waldner > > Best regards, > Angel coreboot-4.15-346-g096d97c3c6-dirty Tue Nov 30 17:10:13 UTC 2021 bootblock starting (log level: 7)... FMAP: Found "FLASH" version 1.1 at 0x0. FMAP: base = 0xfffc size = 0x4 #areas = 3 FMAP: area COREBOOT found @ 200 (261632 bytes)
[coreboot] Re: How to maintain AGESA-based ports long-term?
On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov wrote: > > Personally I don't see any reason for branching, if 99% of the rest of > coreboot code (payloads etc.) is compatible. This will only get us > outdated for these components on this branch, which otherwise could > (and should) be kept simultaneously up-to-date to get the latest > goodies. So, just make two folders: 1 - resource allocator v3, 2 - > resource allocator v4, and access either v3 or v4 from outside > depending on your board selection. This can work, however it depends on how much other code is impacted. A good example of this is the new SMM module loader introduced recently to accommodate CPUs with >32 threads (CB:43684). It was merged with "v2" in the filename so that work could continue on newer server CPUs while the original loader was still in use everywhere else. After some time spent testing it, the "v2" module loader became the default and "v2" was dropped from the name (CB:51528). In that case the code was isolated and the newer version was essentially a drop-in replacement. But even then, there was at least one known case where something broke (CB:52765). For something like the resource allocator I would expect a lot more dependencies on other parts of the tree. This can turn into a big and difficult-to-debug mess if code beyond the resource allocator has different behaviors depending on which version is being used. tl;dr: What you suggest is possible, but cost and benefit need to be considered and the cost can be very high if other parts of the codebase are impacted. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to maintain AGESA-based ports long-term?
Personally I don't see any reason for branching, if 99% of the rest of coreboot code (payloads etc.) is compatible. This will only get us outdated for these components on this branch, which otherwise could (and should) be kept simultaneously up-to-date to get the latest goodies. So, just make two folders: 1 - resource allocator v3, 2 - resource allocator v4, and access either v3 or v4 from outside depending on your board selection. пн, 29 нояб. 2021 г. в 18:53, Nico Huber : > > On 29.11.21 15:58, awokd wrote: > > Nico Huber: > >> On 29.11.21 14:49, awokd wrote: > > Branching > - > I know some people are easily offended by the thought, but I want to > mention it anyway as it seems to me like a cheap solution for the com- > munity as a whole. We could maintain platforms on separate branches. > >>> > >>> Is this different than the status quo? > >> > >> Yes, these ports wouldn't hold the master branch back anymore. > > > > Meant the status quo approach of deprecating boards and leaving to an > > older branch. I think you are saying it would be a named branch instead. > > > > Well, if I wanted to maintain a branch I would make it dedicated to > these specific ports. That would probably be easier to maintain than > a release branch that covers all ports of the given time. Also, it > seems to me that leaving things on an anonymous release branch provides > too much hope that somebody else will do the work ;) > > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Branden, On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote: > > I wasn't really sure that I wanted to comment on this, but seeing as > how I have some of the affected boards I guess I should. Thank you very much. > Angel Pons wrote: > > Besides AMD AGESA boards, the other boards that need to be updated are > > AOpen DXPL > > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board > > in the tree uses > > the same chipset code) and various Asus P2B boards (which support Pentium > > 2/3 CPUs, these > > boards are older than me). Even though I only know two people who still > > have some of these > > boards (and they don't have the same boards), they're still supported > > because the code has > > been maintained so far. > > I am one of the two with Asus P2B boards, with Keith Hui being the > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > P2B-LS. > So far there have not been very many changes and Keith Hui and others > have worked on them, all I've done is test master and relevant patch > sets every once in a while. > I know I have not been uploading board_status results and I have not > gotten around to fixing the variant set up for the P2-99 so I'm not > uploading results that are uncertain about which board they are for. > Not really relevant, but I think it is pretty neat to be running > coreboot on boards older then some of the contributors. > > Mike Banon wrote: > > I am often build-testing my boards (didn't notice a > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but > > only because I've been > > re-using the previously built toolchains to save time). Also, I am actively > > tech-supporting all the > > people who would like to build coreboot for AMD boards from this list, even > > right now I am in an > > active message exchange with >10 people who are switching to these boards > > to run coreboot > > on them - and any user may give back to the project one day. > > I actually have a few AMD boards and laptops that might be viable for > porting to, but I've never looked in to it much because of the state > support is in coreboot and the fact most of the hardware was actively > being used. > > Arthur Heymans wrote: > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > > the codepath for > > SMM_ASEG. This code is used to start APs and do some feature programming on > > each AP, but > > also set up SMM. This has largely been superseded by PARALLEL_MP, which > > should be able > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > > reason for > > deprecation is that having 2 codepaths to do the virtually the same > > increases maintenance > > burden on the community a lot, while also being rather confusing. > > > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on > > single core > > systems. It's likely easy to extend PARALLEL_MP or write some code that > > just does CPU > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > > 0xb) region. A > > POC showed that it's not that hard to do with PARALLEL_MP > > https://review.coreboot.org/c/coreboot/+/58700 > > I didn't even know that was a problem until now. I doubt there is much > I can do about it myself at this point in time, though I can try to > look through it I guess. Looks like Arthur has already implemented some changes to use PARALLEL_MP on i440bx. As of writing, the patches assume there's only one CPU (I already pointed out this is incorrect for boards with two CPU sockets/slots). I'd greatly appreciate if Keith and/or you could test them on actual hardware. The patches to apply, in order, are: https://review.coreboot.org/59694 https://review.coreboot.org/59695 https://review.coreboot.org/59692 https://review.coreboot.org/59693 > Branden Waldner > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
