coreboot May 2020

coreboot@coreboot.org

43 participants
45 discussions

[GLKRVP2] OED audio driver with yellow bang
by ctlin0＠nuvoton.com 19 May '20

19 May '20

Hi all, I use origin/4.11_branch to build coreboot with Tianocore payload (UEFIPayload) for my glkrvp2(CPU stepping=A1). So far, I can boot up and finished WIN10_x64(RS5) installation. My glkrvp2 had reworked to i2s interface. After I install Intel audio related drivers (audio bus and OED), I still see OED audio driver with yellow bang(STATUS_DEVICE_POWER_FAILURE). Currently, I use WHQL audio drivers => Driver version is 9.22.0.3565; Driver Date is 5/15/2018 Suppose the WHQL driver is well, would the coreboot lack of patch or some actions from coreboot initial? As far as I know, OED audio driver will expose/manage some I2S devices, such as BT, DMIC and ISST_I2S(master). If it can't probe/init successfully, I2S related drivers will not work.

1 0

I need an enhanced way to configure Super I/O devices.
by Keith Hui 19 May '20

19 May '20

All, Some of you have seen in my mainboard port [1] that I'm trying to make a couple dozen configuration changes to my board's Super I/O chip the NCT6779D. My initial attempt to describe them in devicetree.cb was ignored because they were not fully described in superio/nuvoton/nct6779d/superio.c as resources. Configuring them in bootblock (or romstage) raises another dilemma: Either I iterate over an array of register/value pairs at the expense of code readability, or code them directly with pnp_write_config() at the expense of bigger code size. And in either case it seems not all changes I made stick in the end (i.e. when looked at using superiotool -d). Then I investigated if I can modify ramstage. The pnp_info struct in superio.c has a 32-bit flag to describe available configuration registers. Each register in 0xf0~0xfe are individually covered by one bit in the flag, taking 15 bits. Much of my config needs lie in the 0xe0~0xee range, meaning another 15 bits and no room in this value to cover them all. Grouping multiple registers into one bit (eg. one bit represents 0xe0~0xe3 as registers we can set in devicetree.cb) isn't practical either because no two Super I/Os will have the same register layout. So this method is insufficient and I cannot extend it. Another approach is to introduce eg. a "reg" keyword that would let me set a value into register whatever, thereby shifting responsibility for correctness to the contributor. Unfortunately I know nothing about how sconfig works or how devicetree.cb get parsed into C code that get called in ramstage, so I could not just do it myself. Bottom line is, I need a way to make many configuration changes to multiple logical devices that are in registers 0xe0-0xfe. Ideas? Or there's one I overlooked? Thanks Keith [1] https://review.coreboot.org/c/coreboot/+/38988

1 0

Re: i440BX regression
by Keith Hui 18 May '20

18 May '20

Hi guys, 31ab7de51a is CB:41368, cherry picked into my local repo. Turns out I have to back out all four of Furquan's patches (CB:39486~39489) for my board to boot normally again. Thoughts? I'll now get a log with everything in at SPEW. On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <adurbin(a)google.com> wrote: > > Keith, is it possible to have the console log level set to SPEW? I'm not seeing the full logs to piece it all together. > > Allocating resources... > Reading resources... > Setting RAM size to 768 MB > PNP: 03f0.8 missing read_resources > Done reading resources. > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) > Resource ranges: > Base: 1000, Size: d000, Tag: 100 > Base: f000, Size: 1000, Tag: 100 > Resource ranges: > Base: 0, Size: ff800000, Tag: 200 > Base: 100000000, Size: f00000000, Tag: 100200 > Resource ranges: > Base: 10000000, Size: 8000000, Tag: 1200 > Resource ranges: > Base: 18000000, Size: 1100000, Tag: 200 > > This is the memory address space: > Base: 0, Size: ff800000, Tag: 200 > Base: 100000000, Size: f00000000, Tag: 100200 > > Those are valid ranges to choose dynamic resources from. > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size 0x10000000 gran 0x1c prefmem > > I see 'Setting RAM size to 768 MB' which means I would expect to see a hole in the ranges representing 768MiB. > > that would be bad. I don't know what commit '31ab7de51a' is, but it might not contain the CB:41368. Having SPEW logs would be helpful. > > Also, what mainboard Kconfig are you selecting for p3bf? src/mainboard/asus/p2b ? > > > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <buurin(a)gmail.com> wrote: >> >> (Temporarily leaving the list out) >> >> Hi Aaron, >> >> Here is a log with everything including CB:41368 included. I'll get >> this log out to you first, while I try a build with all problem >> commits left out. >> >> Thanks >> Keith >> >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buurin(a)gmail.com> wrote: >> >> >> >> Hi guys, >> >> >> >> I tested these fixes on my board, and I have to say there's still >> >> something wrong. They did address the hang or reset in SeaBIOS I first >> >> described, but now either my ATA hard drive failed to boot (it tried >> >> to hand off to GRUB on my drive, but didn't get there), or it can't >> >> find the option ROM of my video card, meaning no display. >> >> >> >> Now I want to try the other way, testing a build with all changes >> >> related to the problem backed out instead. So besides the one I first >> >> identified, what other related patches should I try backing out? >> > >> > >> > Just go to the parent of the identified patch. As for the other symptoms you are seeing, I'd love to see logs with the patches we identified so we can root cause. >> > >> > Thanks. >> > >> > -Aaron >> > >> >> >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh >> >> <furquan.m.shaikh(a)gmail.com> wrote: >> >> > >> >> > Similar fix for i440x: https://review.coreboot.org/c/coreboot/+/41368 >> >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin <adurbin(a)google.com> wrote: >> >> > > >> >> > > i440x chipset is doing things in the wrong way like sandybridge. I uploaded this fix for sandy: https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the equivalent for i440x. >> >> > > >> >> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin <adurbin(a)google.com> wrote: >> >> > >> >> >> > >> OK. I'll take a look at your logs and see what's going on. The patch link I sent was based off of someone else's mainboard logs. >> >> > >> >> >> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui <buurin(a)gmail.com> wrote: >> >> > >>> >> >> > >>> Hi Aaron, >> >> > >>> >> >> > >>> It didn't help. There still a way out of whack entry in the coreboot >> >> > >>> table and e820 entry ending at 000003ffffffffff, which I think have >> >> > >>> more to do than the 41363's scope. >> >> > >>> >> >> > >>> Keith >> >> > >>> >> >> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin <adurbin(a)google.com> wrote: >> >> > >>> > >> >> > >>> > I think the following patch will fix things up: https://review.coreboot.org/c/coreboot/+/41363 Please let me know. >> >> > >>> > >> >> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui <buurin(a)gmail.com> wrote: >> >> > >>> >> >> >> > >>> >> Thanks Furquan. >> >> > >>> >> >> >> > >>> >> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2 >> >> > >>> >> is at the problem commit. Log 3 is at the current master, if that's >> >> > >>> >> what you meant by ToT. >> >> > >>> >> >> >> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config >> >> > >>> >> before taking these logs. All 3 runs are taken using the same SeaBIOS >> >> > >>> >> binary. >> >> > >>> >> >> >> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the >> >> > >>> >> payload used in run 3, and took an extra run. In this case the board >> >> > >>> >> reset on its own at "Scanning option roms", looping infinitely. >> >> > >>> >> >> >> > >>> >> Hope this helps >> >> > >>> >> Keith >> >> > >>> >> >> >> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh >> >> > >>> >> <furquan.m.shaikh(a)gmail.com> wrote: >> >> > >>> >> > >> >> > >>> >> > Thanks for the report Keith! >> >> > >>> >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> >> > >>> >> > > >> >> > >>> >> > > Dear Keith, >> >> > >>> >> > > >> >> > >>> >> > > >> >> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui: >> >> > >>> >> > > >> >> > >>> >> > > > I am still refining the P2B family of boards, now including the >> >> > >>> >> > > > infamous P3B-F with an unusual appetite for hacks to make work. >> >> > >>> >> > > > >> >> > >>> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries >> >> > >>> >> > > > to relocate itself as part of its usual chores. Having just learned >> >> > >>> >> > > > git bisect, I decided to try it out. >> >> > >>> >> > > > >> >> > >>> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke >> >> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as >> >> > >>> >> > > > P3B-F, but I still want to blame that, and probably the very next >> >> > >>> >> > > > commit as well, as they both deal with some very modern aspects of PCI >> >> > >>> >> > > > that well predates the 440BX. >> >> > >>> >> > > > >> >> > >>> >> > > > Is there anything we can do to fix 3b02006afe? >> >> > >>> >> > > >> >> > >>> >> > > I commented in the change-set [1] to make the author and reviewers aware >> >> > >>> >> > > of this issue and referenced your list message, and ask to comment here. >> >> > >>> >> > > >> >> > >>> >> > > Could you please provide the debug log of coreboot and SeaBIOS? >> >> > >>> >> > >> >> > >>> >> > As Paul mentioned, can you please provide the debug logs for coreboot >> >> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the change >> >> > >>> >> > 3b02006afe where it does not hang? Thanks! >> >> > >>> >> > >> >> > >>> >> > > >> >> > >>> >> > > >> >> > >>> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which got a >> >> > >>> >> > > > heavy workout during this bisect, through vendor firmware and both >> >> > >>> >> > > > good and bad builds of coreboot. In all cases I can flash internal, no >> >> > >>> >> > > > longer having to haul out my P2B-LS just to use it as a flasher. >> >> > >>> >> > > > >> >> > >>> >> > > > Enjoy this long overdue board enable. If it gets submitted, I'll >> >> > >>> >> > > > retract the ramstage hack[3] doing the same as redundant. >> >> > >>> >> > > >> >> > >>> >> > > Very nice! It’s always amazing, how after so many years, when the vendor >> >> > >>> >> > > already stopped supporting the device, the community still supports the >> >> > >>> >> > > device and improves the firmware showing that Free Software is the more >> >> > >>> >> > > sustainable way. >> >> > >>> >> > > >> >> > >>> >> > > >> >> > >>> >> > > Kind regards, >> >> > >>> >> > > >> >> > >>> >> > > Paul >> >> > >>> >> > > >> >> > >>> >> > > >> >> > >>> >> > > > [1] https://review.coreboot.org/c/coreboot/+/39486 >> >> > >>> >> > > > [2] https://review.coreboot.org/c/flashrom/+/41354 >> >> > >>> >> > > > [3] https://review.coreboot.org/c/coreboot/+/41224 >> >> > >>> >> > > _______________________________________________ >> >> > >>> >> > > coreboot mailing list -- coreboot(a)coreboot.org >> >> > >>> >> > > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> >> > >>> >> _______________________________________________ >> >> > >>> >> coreboot mailing list -- coreboot(a)coreboot.org >> >> > >>> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org

8 19

Documenting changes and so on
by Patrick Georgi 18 May '20

18 May '20

Hi everybody, during last week's issue with the resource allocator there have been some remarks about how the change seemed practically invisible despite being on Gerrit for 2 months and some people suggested that it would be useful to have better documentation with such changes on why they're done and what the former situation has been. I created https://review.coreboot.org/c/coreboot/+/41493 to add this aspect to the reviewing guidelines, to remind contributors to document and to invite feedback on the mailing list; to provide suggestions to contributors where such documentation could end up; and also to make sure that reviewers feel empowered to ask for more docs and/or discussion (by pointing at the guidelines if necessary). I hope this allows improving our review culture so that things don't fall through the cracks in the future (or at least, less often) without becoming too rigid (please do not use this section to demand typo fixes discussions on the list, please ;-) ) Please take a look, comment, disagree, and so on. Thanks, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Need help with getting KGPE-D16 working.
by ragnaros＠tenebr.is 16 May '20

16 May '20

Recently I'm finally able to get a KGPE-D16 coreboot environment that could always boot, although there are a lot of issues and questions. I'm currently using the 4.11 branch as this board has been dropped in the master branch. The main issue is memory. It seems there are still issues with memory initialization. The Samsung 16GB sticks I currently have (normal or VLP) do not work when using all orange slots, ending in a bootloop due to DIMM training failure (which is the same error I had when I was trying coreboot on KCMA-D8). However, on KGPE-D16, by installing the 8 sticks to the following slots: D1/D2, B1/B2, E1/E2 and G1/G2, I could always get it past the memory initialization, albeit with this error: "TrainDQSRdWrPos: negative DQS recovery delay detected! Attempting to continue but your system may be unstable..." This is currently the only combination that could always boot (and with all 128GB recognized). Other combinations I tested either resulted in some "HARDWARE FAULT: HT_EVENT_HW_SYNCHFLOOD" errors which would soft reset before even reaching the DIMM training part, or it entered the DIMM training part but would never complete. However, the system is currently not at a point that could properly boot to a system (or even a payload) yet. As of yesterday, the only thing I could boot and steadily function is a Menuet64 floppy image. 1. I'm using SeaBIOS master, and have put several floppy images into the CBFS, but it seems to only list the last floppy image I added as a boot option (Ramdisk). It appears multiple floppy images is not officially supported in master yet and I've just located the patch regarding this. I'm still new to SeaBIOS so I'm not sure how to modify configuration/bootorder later on, as I currently don't have a configuration/bootorder file supplied and let it use default values. 2. None of the secondary payloads work. nvramcui hangs with something like "unable to init curs" (I only tried it once and couldn't remember what exactly it is). coreinfo and tint hangs with this "Not enough memory creating EHCI periodic frame list." error. memtest could load, but when it starts testing, it hangs with a glitched screen of blinking characters, among which something like "d h l p t x" could be seen. This also happened when using memtest that comes with the Manjaro Linux boot USB. 3. Initially I had issues with graphical bootloaders like grub, but after disabling bootsplash image as well as not building the seavgabios.bin (by unchecking the "Include generated option rom that implements legacy VGA BIOS compatibility"), I could get Manjaro's graphical grub to load, but still cannot boot to the kernel (XZ-Compressed Data is corrupt). Maybe this is due to memory, as I think the combination I previously mentioned only guaranteed it to go past the training part, but not anything after that. 4. Does this board support any other graphical initialization methods? It seems I can only choose "native graphics init" as well as "legacy VGA text mode" framebuffer. I use SeaBIOS with a dedicated nVidia video card (onboard not used), and it seems without bootsplash image or seavgabios.bin I'm able to load something graphical (such as grub and Menuet64). 5. It seems the board would ramp up the fans to max once it passes the DIMM training and memory clear part (the fans seem to spin at a relatively quiet speed before that, similar to Stock BIOS' Generic profile). As the CPU fans I'm currently using can be really noisy at more than 4300 rpm max, I ended up using a 5.25'' external fan controller (non-PWM) and manually toned it down to an acceptable 2900 rpm (it seems I can't get it to any lower without using a PWM-capable controller). Is there a way to tweak the fan control profiles of the onboard CPU fan ports like the stock BIOS? This is the first time I ever manage to get a bootable coreboot system, so I'm not sure which part to look into for my issues, especially the RAM part. Is there an up-to-date RAM HCL and guidelines for this board? At this point, I can always power it on to conduct more tests on this board for any additional logs if needed.

6 9

Help unsubscribe `
by Dan Collins 15 May '20

15 May '20

Help unsubscribe -----Original Message----- From: coreboot-request(a)coreboot.org <coreboot-request(a)coreboot.org> Sent: 15 May 2020 13:56 To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 183, Issue 25 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Help unsubscribe (Dan Collins) ---------------------------------------------------------------------- Date: Fri, 15 May 2020 12:56:15 +0000 From: Dan Collins <dan.collins(a)ircona.com> Subject: [coreboot] Help unsubscribe To: "coreboot(a)coreboot.org" <coreboot(a)coreboot.org> Message-ID: <DB6PR04MB29817B043E9CDD70C6A4AD3FA0BD0(a)DB6PR04MB2981.eur prd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Help unsubscribe -----Original Message----- From: coreboot-request(a)coreboot.org <coreboot-request(a)coreboot.org> Sent: 14 May 2020 23:55 To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 183, Issue 21 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: Resource allocator: multiple boards regression (Keith Hui) 2. Re: Resource allocator: multiple boards regression (Aaron Durbin) ---------------------------------------------------------------------- Date: Thu, 14 May 2020 18:50:30 -0400 From: Keith Hui <buurin(a)gmail.com> Subject: [coreboot] Re: Resource allocator: multiple boards regression To: Aaron Durbin <adurbin(a)google.com> Cc: Mike Banon <mikebdp2(a)gmail.com>, Furquan Shaikh <furquan.m.shaikh(a)gmail.com>, coreboot <coreboot(a)coreboot.org> Message-ID: <CANTF=bTr=N8i-PZX0coB-uNE4FVXa8OEjk=CFT2rdrvhqxdjpQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi Aaron, You may want to check the QEMU-q35 target as well: Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 Emulation targets: "QEMU x86 q35/ich9" using payload TianoCore : FAIL : https://lava.9esec.io/r/3427 "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : https://lava.9esec.io/r/3426 "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/3425 "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS : https://lava.9esec.io/r/3424 Thanks Keith On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <adurbin(a)google.com> wrote: > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikebdp2(a)gmail.com> wrote: >> >> Unfortunately it seems a lot of boards are affected by this. A88XM-E >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at >> booting - and, when they do, no boot devices are available (virtual >> floppies too, for some reason) - except coreinfo/tint secondary >> payloads which became prone to freezing. I attach the A88XM-E logs >> I've been able to obtain with USB FT232H: >> >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot >> repo's revision where all the stuff works >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit >> got the boards broken for the first time >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log >> for coreboot's master top >> >> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2 >> EHCI Debug Port hook triggered". >> >> I hope these commits could be reverted before we figure out what's >> going on with them. Good thing we've noticed it fast enough. >> > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is fundamentally broken and at odds with all of the resource allocation flow. They worked previously because dynamic resources were being assigned using an algorithm that just assumed there weren't collisions, and that was done w/o all the necessary info required for making the proper decisions regarding dynamic resource allocation. > > I landed the other chipsets' fixes, but the amd chipset code is going to take a lot more to fix. Would you be willing to test patches as they are crafted? Given the largeness of the problem as well as the gnarly code that is the amd chipset code it's going to take some time so I think we do need to revert the allocator changes until we can do some house keeping. > > -Aaron >> >> Best regards, >> Mike Banon >> >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <buurin(a)gmail.com> wrote: >> > >> > Hi guys, >> > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. >> > >> > Turns out I have to back out all four of Furquan's patches >> > (CB:39486~39489) for my board to boot normally again. >> > >> > Thoughts? >> > >> > I'll now get a log with everything in at SPEW. >> > >> > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <adurbin(a)google.com> wrote: >> > > >> > > Keith, is it possible to have the console log level set to SPEW? I'm not seeing the full logs to piece it all together. >> > > >> > > Allocating resources... >> > > Reading resources... >> > > Setting RAM size to 768 MB >> > > PNP: 03f0.8 missing read_resources >> > > Done reading resources. >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) >> > > Resource ranges: >> > > Base: 1000, Size: d000, Tag: 100 >> > > Base: f000, Size: 1000, Tag: 100 >> > > Resource ranges: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > Resource ranges: >> > > Base: 10000000, Size: 8000000, Tag: 1200 >> > > Resource ranges: >> > > Base: 18000000, Size: 1100000, Tag: 200 >> > > >> > > This is the memory address space: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > >> > > Those are valid ranges to choose dynamic resources from. >> > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size 0x10000000 gran 0x1c prefmem >> > > >> > > I see 'Setting RAM size to 768 MB' which means I would expect to see a hole in the ranges representing 768MiB. >> > > >> > > that would be bad. I don't know what commit '31ab7de51a' is, but it might not contain the CB:41368. Having SPEW logs would be helpful. >> > > >> > > Also, what mainboard Kconfig are you selecting for p3bf? src/mainboard/asus/p2b ? >> > > >> > > >> > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >> (Temporarily leaving the list out) >> > >> >> > >> Hi Aaron, >> > >> >> > >> Here is a log with everything including CB:41368 included. I'll get >> > >> this log out to you first, while I try a build with all problem >> > >> commits left out. >> > >> >> > >> Thanks >> > >> Keith >> > >> >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> >> > >> >> Hi guys, >> > >> >> >> > >> >> I tested these fixes on my board, and I have to say there's still >> > >> >> something wrong. They did address the hang or reset in SeaBIOS I first >> > >> >> described, but now either my ATA hard drive failed to boot (it tried >> > >> >> to hand off to GRUB on my drive, but didn't get there), or it can't >> > >> >> find the option ROM of my video card, meaning no display. >> > >> >> >> > >> >> Now I want to try the other way, testing a build with all changes >> > >> >> related to the problem backed out instead. So besides the one I first >> > >> >> identified, what other related patches should I try backing out? >> > >> > >> > >> > >> > >> > Just go to the parent of the identified patch. As for the other symptoms you are seeing, I'd love to see logs with the patches we identified so we can root cause. >> > >> > >> > >> > Thanks. >> > >> > >> > >> > -Aaron >> > >> > >> > >> >> >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh >> > >> >> <furquan.m.shaikh(a)gmail.com> wrote: >> > >> >> > >> > >> >> > Similar fix for i440x: https://review.coreboot.org/c/coreboot/+/41368 >> > >> >> > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > > >> > >> >> > > i440x chipset is doing things in the wrong way like sandybridge. I uploaded this fix for sandy: https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the equivalent for i440x. >> > >> >> > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > >> >> > >> >> > >> OK. I'll take a look at your logs and see what's going on. The patch link I sent was based off of someone else's mainboard logs. >> > >> >> > >> >> > >> >> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >>> >> > >> >> > >>> Hi Aaron, >> > >> >> > >>> >> > >> >> > >>> It didn't help. There still a way out of whack entry in the coreboot >> > >> >> > >>> table and e820 entry ending at 000003ffffffffff, which I think have >> > >> >> > >>> more to do than the 41363's scope. >> > >> >> > >>> >> > >> >> > >>> Keith >> > >> >> > >>> >> > >> >> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > >>> > >> > >> >> > >>> > I think the following patch will fix things up: https://review.coreboot.org/c/coreboot/+/41363 Please let me know. >> > >> >> > >>> > >> > >> >> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >>> >> >> > >> >> > >>> >> Thanks Furquan. >> > >> >> > >>> >> >> > >> >> > >>> >> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2 >> > >> >> > >>> >> is at the problem commit. Log 3 is at the current master, if that's >> > >> >> > >>> >> what you meant by ToT. >> > >> >> > >>> >> >> > >> >> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config >> > >> >> > >>> >> before taking these logs. All 3 runs are taken using the same SeaBIOS >> > >> >> > >>> >> binary. >> > >> >> > >>> >> >> > >> >> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the >> > >> >> > >>> >> payload used in run 3, and took an extra run. In this case the board >> > >> >> > >>> >> reset on its own at "Scanning option roms", looping infinitely. >> > >> >> > >>> >> >> > >> >> > >>> >> Hope this helps >> > >> >> > >>> >> Keith >> > >> >> > >>> >> >> > >> >> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh >> > >> >> > >>> >> <furquan.m.shaikh(a)gmail.com> wrote: >> > >> >> > >>> >> > >> > >> >> > >>> >> > Thanks for the report Keith! >> > >> >> > >>> >> > >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Dear Keith, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > I am still refining the P2B family of boards, now including the >> > >> >> > >>> >> > > > infamous P3B-F with an unusual appetite for hacks to make work. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries >> > >> >> > >>> >> > > > to relocate itself as part of its usual chores. Having just learned >> > >> >> > >>> >> > > > git bisect, I decided to try it out. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke >> > >> >> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as >> > >> >> > >>> >> > > > P3B-F, but I still want to blame that, and probably the very next >> > >> >> > >>> >> > > > commit as well, as they both deal with some very modern aspects of PCI >> > >> >> > >>> >> > > > that well predates the 440BX. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Is there anything we can do to fix 3b02006afe? >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > I commented in the change-set [1] to make the author and reviewers aware >> > >> >> > >>> >> > > of this issue and referenced your list message, and ask to comment here. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Could you please provide the debug log of coreboot and SeaBIOS? >> > >> >> > >>> >> > >> > >> >> > >>> >> > As Paul mentioned, can you please provide the debug logs for coreboot >> > >> >> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the change >> > >> >> > >>> >> > 3b02006afe where it does not hang? Thanks! >> > >> >> > >>> >> > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which got a >> > >> >> > >>> >> > > > heavy workout during this bisect, through vendor firmware and both >> > >> >> > >>> >> > > > good and bad builds of coreboot. In all cases I can flash internal, no >> > >> >> > >>> >> > > > longer having to haul out my P2B-LS just to use it as a flasher. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Enjoy this long overdue board enable. If it gets submitted, I'll >> > >> >> > >>> >> > > > retract the ramstage hack[3] doing the same as redundant. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Very nice! It’s always amazing, how after so many years, when the vendor >> > >> >> > >>> >> > > already stopped supporting the device, the community still supports the >> > >> >> > >>> >> > > device and improves the firmware showing that Free Software is the more >> > >> >> > >>> >> > > sustainable way. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Kind regards, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Paul >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > [1] https://review.coreboot.org/c/coreboot/+/39486 >> > >> >> > >>> >> > > > [2] https://review.coreboot.org/c/flashrom/+/41354 >> > >> >> > >>> >> > > > [3] https://review.coreboot.org/c/coreboot/+/41224 >> > >> >> > >>> >> > > _______________________________________________ >> > >> >> > >>> >> > > coreboot mailing list -- coreboot(a)coreboot.org >> > >> >> > >>> >> > > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >> >> > >>> >> _______________________________________________ >> > >> >> > >>> >> coreboot mailing list -- coreboot(a)coreboot.org >> > >> >> > >>> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ Date: Thu, 14 May 2020 16:54:29 -0600 From: Aaron Durbin <adurbin(a)google.com> Subject: [coreboot] Re: Resource allocator: multiple boards regression To: Keith Hui <buurin(a)gmail.com> Cc: Mike Banon <mikebdp2(a)gmail.com>, Furquan Shaikh <furquan.m.shaikh(a)gmail.com>, coreboot <coreboot(a)coreboot.org> Message-ID: <CAE2855tBax_piH9+dGeFeu3dWHF6+VQkZ6oWPBCL2hCNhaDFOw(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="00000000000010123505a5a3957a" --00000000000010123505a5a3957a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2020 at 4:44 PM Keith Hui <buurin(a)gmail.com> wrote: > Hi Aaron, > > You may want to check the QEMU-q35 target as well: > > Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 > Emulation targets: > "QEMU x86 q35/ich9" using payload TianoCore : FAIL : > https://lava.9esec.io/r/3427 > "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : > https://lava.9esec.io/r/3426 > "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : > https://lava.9esec.io/r/3425 > "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS : > https://lava.9esec.io/r/3424 Ya. Those are fixed from the patches that fixed your device, Keith. > > > Thanks > Keith > > On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <adurbin(a)google.com> wrote: > > > > > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikebdp2(a)gmail.com> wrote: > >> > >> Unfortunately it seems a lot of boards are affected by this. A88XM-E > >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at > >> booting - and, when they do, no boot devices are available (virtual > >> floppies too, for some reason) - except coreinfo/tint secondary > >> payloads which became prone to freezing. I attach the A88XM-E logs > >> I've been able to obtain with USB FT232H: > >> > >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot > >> repo's revision where all the stuff works > >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit > >> got the boards broken for the first time > >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log > >> for coreboot's master top > >> > >> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2 > >> EHCI Debug Port hook triggered". > >> > >> I hope these commits could be reverted before we figure out what's > >> going on with them. Good thing we've noticed it fast enough. > >> > > > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is > fundamentally broken and at odds with all of the resource allocation flow= . > They worked previously because dynamic resources were being assigned usin= g > an algorithm that just assumed there weren't collisions, and that was don= e > w/o all the necessary info required for making the proper decisions > regarding dynamic resource allocation. > > > > I landed the other chipsets' fixes, but the amd chipset code is going t= o > take a lot more to fix. Would you be willing to test patches as they are > crafted? Given the largeness of the problem as well as the gnarly code th= at > is the amd chipset code it's going to take some time so I think we do nee= d > to revert the allocator changes until we can do some house keeping. > > > > -Aaron > >> > >> Best regards, > >> Mike Banon > >> > >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <buurin(a)gmail.com> wrote: > >> > > >> > Hi guys, > >> > > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. > >> > > >> > Turns out I have to back out all four of Furquan's patches > >> > (CB:39486~39489) for my board to boot normally again. > >> > > >> > Thoughts? > >> > > >> > I'll now get a log with everything in at SPEW. > >> > > >> > > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <adurbin(a)google.com> > wrote: > >> > > > >> > > Keith, is it possible to have the console log level set to SPEW? > I'm not seeing the full logs to piece it all together. > >> > > > >> > > Allocating resources... > >> > > Reading resources... > >> > > Setting RAM size to 768 MB > >> > > PNP: 03f0.8 missing read_resources > >> > > Done reading resources. > >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) > >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) > >> > > Resource ranges: > >> > > Base: 1000, Size: d000, Tag: 100 > >> > > Base: f000, Size: 1000, Tag: 100 > >> > > Resource ranges: > >> > > Base: 0, Size: ff800000, Tag: 200 > >> > > Base: 100000000, Size: f00000000, Tag: 100200 > >> > > Resource ranges: > >> > > Base: 10000000, Size: 8000000, Tag: 1200 > >> > > Resource ranges: > >> > > Base: 18000000, Size: 1100000, Tag: 200 > >> > > > >> > > This is the memory address space: > >> > > Base: 0, Size: ff800000, Tag: 200 > >> > > Base: 100000000, Size: f00000000, Tag: 100200 > >> > > > >> > > Those are valid ranges to choose dynamic resources from. > >> > > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size 0x10000000 > gran 0x1c prefmem > >> > > > >> > > I see 'Setting RAM size to 768 MB' which means I would expect to > see a hole in the ranges representing 768MiB. > >> > > > >> > > that would be bad. I don't know what commit '31ab7de51a' is, but i= t > might not contain the CB:41368. Having SPEW logs would be helpful. > >> > > > >> > > Also, what mainboard Kconfig are you selecting for p3bf? > src/mainboard/asus/p2b ? > >> > > > >> > > > >> > > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <buurin(a)gmail.com> > wrote: > >> > >> > >> > >> (Temporarily leaving the list out) > >> > >> > >> > >> Hi Aaron, > >> > >> > >> > >> Here is a log with everything including CB:41368 included. I'll g= et > >> > >> this log out to you first, while I try a build with all problem > >> > >> commits left out. > >> > >> > >> > >> Thanks > >> > >> Keith > >> > >> > >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <adurbin(a)google.com= > > wrote: > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buurin(a)gmail.com> > wrote: > >> > >> >> > >> > >> >> Hi guys, > >> > >> >> > >> > >> >> I tested these fixes on my board, and I have to say there's > still > >> > >> >> something wrong. They did address the hang or reset in SeaBIOS > I first > >> > >> >> described, but now either my ATA hard drive failed to boot (it > tried > >> > >> >> to hand off to GRUB on my drive, but didn't get there), or it > can't > >> > >> >> find the option ROM of my video card, meaning no display. > >> > >> >> > >> > >> >> Now I want to try the other way, testing a build with all > changes > >> > >> >> related to the problem backed out instead. So besides the one = I > first > >> > >> >> identified, what other related patches should I try backing ou= t? > >> > >> > > >> > >> > > >> > >> > Just go to the parent of the identified patch. As for the othe= r > symptoms you are seeing, I'd love to see logs with the patches we > identified so we can root cause. > >> > >> > > >> > >> > Thanks. > >> > >> > > >> > >> > -Aaron > >> > >> > > >> > >> >> > >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh > >> > >> >> <furquan.m.shaikh(a)gmail.com> wrote: > >> > >> >> > > >> > >> >> > Similar fix for i440x: > https://review.coreboot.org/c/coreboot/+/41368 > >> > >> >> > > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > > > >> > >> >> > > i440x chipset is doing things in the wrong way like > sandybridge. I uploaded this fix for sandy: > https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the > equivalent for i440x. > >> > >> >> > > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > >> > >> > >> >> > >> OK. I'll take a look at your logs and see what's going on= . > The patch link I sent was based off of someone else's mainboard logs. > >> > >> >> > >> > >> > >> >> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui < > buurin(a)gmail.com> wrote: > >> > >> >> > >>> > >> > >> >> > >>> Hi Aaron, > >> > >> >> > >>> > >> > >> >> > >>> It didn't help. There still a way out of whack entry in > the coreboot > >> > >> >> > >>> table and e820 entry ending at 000003ffffffffff, which I > think have > >> > >> >> > >>> more to do than the 41363's scope. > >> > >> >> > >>> > >> > >> >> > >>> Keith > >> > >> >> > >>> > >> > >> >> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > >>> > > >> > >> >> > >>> > I think the following patch will fix things up: > https://review.coreboot.org/c/coreboot/+/41363 Please let me know. > >> > >> >> > >>> > > >> > >> >> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui < > buurin(a)gmail.com> wrote: > >> > >> >> > >>> >> > >> > >> >> > >>> >> Thanks Furquan. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Here are 3 logs. Log 1 is at the commit just before > the problem. Log 2 > >> > >> >> > >>> >> is at the problem commit. Log 3 is at the current > master, if that's > >> > >> >> > >>> >> what you meant by ToT. > >> > >> >> > >>> >> > >> > >> >> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the > attached .config > >> > >> >> > >>> >> before taking these logs. All 3 runs are taken using > the same SeaBIOS > >> > >> >> > >>> >> binary. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT > off, replaced the > >> > >> >> > >>> >> payload used in run 3, and took an extra run. In this > case the board > >> > >> >> > >>> >> reset on its own at "Scanning option roms", looping > infinitely. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Hope this helps > >> > >> >> > >>> >> Keith > >> > >> >> > >>> >> > >> > >> >> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh > >> > >> >> > >>> >> <furquan.m.shaikh(a)gmail.com> wrote: > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > Thanks for the report Keith! > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel < > pmenzel(a)molgen.mpg.de> wrote: > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Dear Keith, > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui: > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > I am still refining the P2B family of boards, > now including the > >> > >> >> > >>> >> > > > infamous P3B-F with an unusual appetite for > hacks to make work. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > That said, I'm now finding that, on P3B-F, > SeaBIOS hangs when it tries > >> > >> >> > >>> >> > > > to relocate itself as part of its usual chores. > Having just learned > >> > >> >> > >>> >> > > > git bisect, I decided to try it out. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > It was commit > 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke > >> > >> >> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the > P8Z77-M as much as > >> > >> >> > >>> >> > > > P3B-F, but I still want to blame that, and > probably the very next > >> > >> >> > >>> >> > > > commit as well, as they both deal with some ver= y > modern aspects of PCI > >> > >> >> > >>> >> > > > that well predates the 440BX. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > Is there anything we can do to fix 3b02006afe? > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > I commented in the change-set [1] to make the > author and reviewers aware > >> > >> >> > >>> >> > > of this issue and referenced your list message, > and ask to comment here. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Could you please provide the debug log of coreboo= t > and SeaBIOS? > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > As Paul mentioned, can you please provide the debug > logs for coreboot > >> > >> >> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD se= t > before the change > >> > >> >> > >>> >> > 3b02006afe where it does not hang? Thanks! > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Meanwhile I ported the P3B-F board enable to > flashrom [2], which got a > >> > >> >> > >>> >> > > > heavy workout during this bisect, through vendo= r > firmware and both > >> > >> >> > >>> >> > > > good and bad builds of coreboot. In all cases I > can flash internal, no > >> > >> >> > >>> >> > > > longer having to haul out my P2B-LS just to use > it as a flasher. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > Enjoy this long overdue board enable. If it get= s > submitted, I'll > >> > >> >> > >>> >> > > > retract the ramstage hack[3] doing the same as > redundant. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Very nice! It=E2=80=99s always amazing, how after= so many > years, when the vendor > >> > >> >> > >>> >> > > already stopped supporting the device, the > community still supports the > >> > >> >> > >>> >> > > device and improves the firmware showing that Fre= e > Software is the more > >> > >> >> > >>> >> > > sustainable way. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Kind regards, > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Paul > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > [1] > https://review.coreboot.org/c/coreboot/+/39486 > >> > >> >> > >>> >> > > > [2] > https://review.coreboot.org/c/flashrom/+/41354 > >> > >> >> > >>> >> > > > [3] > https://review.coreboot.org/c/coreboot/+/41224 > >> > >> >> > >>> >> > > _______________________________________________ > >> > >> >> > >>> >> > > coreboot mailing list -- coreboot(a)coreboot.org > >> > >> >> > >>> >> > > To unsubscribe send an email to > coreboot-leave(a)coreboot.org > >> > >> >> > >>> >> _______________________________________________ > >> > >> >> > >>> >> coreboot mailing list -- coreboot(a)coreboot.org > >> > >> >> > >>> >> To unsubscribe send an email to > coreboot-leave(a)coreboot.org > >> > _______________________________________________ > >> > coreboot mailing list -- coreboot(a)coreboot.org > >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org > --00000000000010123505a5a3957a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif"> </div></div> <div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 14, 2020 at 4:44 PM Keith= Hui <<a href=3D"mailto:buurin@gmail.com">buurin(a)gmail.com</a>> wrote= : </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Aaron, You may want to check the QEMU-q35 target as well: Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 Emulation targets: "QEMU x86 q35/ich9" using payload TianoCore : FAIL : <a href=3D"https://lava.9esec.io/r/3427" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3427</a> "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : <a href=3D"htt= ps://lava.9esec.io/r/3426" rel=3D"noreferrer" target=3D"_blank">https://lav= a.9esec.io/r/3426</a> "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : <a href=3D"https://lava.9esec.io/r/3425" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3425</a> "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS :<b= r> <a href=3D"https://lava.9esec.io/r/3424" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3424</a></blockquote><div> </div><div class= =3D"gmail_default" style=3D"font-family:tahoma,sans-serif">Ya. Those are fi= xed from the patches that fixed your device, Keith.</div><div class=3D"gmai= l_default" style=3D"font-family:tahoma,sans-serif"></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> Thanks Keith On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <<a href=3D"mailto:adurbin@= google.com" target=3D"_blank">adurbin(a)google.com</a>> wrote: > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <<a href=3D"mailto:mikeb= dp2(a)gmail.com" target=3D"_blank">mikebdp2(a)gmail.com</a>> wrote: >> >> Unfortunately it seems a lot of boards are affected by this. A88XM= -E >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed= at >> booting - and, when they do, no boot devices are available (virtua= l >> floppies too, for some reason) - except coreinfo/tint secondary<br= > >> payloads which became prone to freezing. I attach the A88XM-E logs= >> I've been able to obtain with USB FT232H: >> >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot= >> repo's revision where all the stuff works >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this comm= it >> got the boards broken for the first time >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a= log >> for coreboot's master top >> >> For some reason logs for 2) and 3) always stop after "PCI: 00= :12.2 >> EHCI Debug Port hook triggered". >> >> I hope these commits could be reverted before we figure out what&#= 39;s >> going on with them. Good thing we've noticed it fast enough.<b= r> >> > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is= fundamentally broken and at odds with all of the resource allocation flow.= They worked previously because dynamic resources were being assigned using= an algorithm that just assumed there weren't collisions, and that was = done w/o all the necessary info required for making the proper decisions re= garding dynamic resource allocation. > > I landed the other chipsets' fixes, but the amd chipset code is go= ing to take a lot more to fix. Would you be willing to test patches as they= are crafted? Given the largeness of the problem as well as the gnarly code= that is the amd chipset code it's going to take some time so I think w= e do need to revert the allocator changes until we can do some house keepin= g. > > -Aaron >> >> Best regards, >> Mike Banon >> >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <<a href=3D"mailto:bu= urin(a)gmail.com" target=3D"_blank">buurin(a)gmail.com</a>> wrote: >> > >> > Hi guys, >> > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. >> > >> > Turns out I have to back out all four of Furquan's patche= s >> > (CB:39486~39489) for my board to boot normally again. >> > >> > Thoughts? >> > >> > I'll now get a log with everything in at SPEW. >> > >> > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <<a href=3D"m= ailto:adurbin@google.com" target=3D"_blank">adurbin(a)google.com</a>> wrot= e: >> > > >> > > Keith, is it possible to have the console log level set = to SPEW? I'm not seeing the full logs to piece it all together. >> > > >> > > Allocating resources... >> > > Reading resources... >> > > Setting RAM size to 768 MB >> > > PNP: 03f0.8 missing read_resources >> > > Done reading resources. >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering req= uirements) >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating re= sources) >> > > Resource ranges: >> > > Base: 1000, Size: d000, Tag: 100 >> > > Base: f000, Size: 1000, Tag: 100 >> > > Resource ranges: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > Resource ranges: >> > > Base: 10000000, Size: 8000000, Tag: 1200 >> > > Resource ranges: >> > > Base: 18000000, Size: 1100000, Tag: 200 >> > > >> > > This is the memory address space: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > >> > > Those are valid ranges to choose dynamic resources from.= >> > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size= 0x10000000 gran 0x1c prefmem >> > > >> > > I see 'Setting RAM size to 768 MB' which means I= would expect to see a hole in the ranges representing 768MiB. >> > > >> > > that would be bad. I don't know what commit '31a= b7de51a' is, but it might not contain the CB:41368. Having SPEW logs wo= uld be helpful. >> > > >> > > Also, what mainboard Kconfig are you selecting for p3bf?= src/mainboard/asus/p2b ? >> > > >> > > >> > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <<a href= =3D"mailto:buurin@gmail.com" target=3D"_blank">buurin(a)gmail.com</a>> wro= te: >> > >> >> > >> (Temporarily leaving the list out) >> > >> >> > >> Hi Aaron, >> > >> >> > >> Here is a log with everything including CB:41368 inc= luded. I'll get >> > >> this log out to you first, while I try a build with = all problem >> > >> commits left out. >> > >> >> > >> Thanks >> > >> Keith >> > >> >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <<a= href=3D"mailto:adurbin@google.com" target=3D"_blank">adurbin(a)google.com</a= >> wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <= <a href=3D"mailto:buurin@gmail.com" target=3D"_blank">buurin(a)gmail.com</a>&= gt; wrote: >> > >> >> >> > >> >> Hi guys, >> > >> >> >> > >> >> I tested these fixes on my board, and I hav= e to say there's still >> > >> >> something wrong. They did address the hang = or reset in SeaBIOS I first >> > >> >> described, but now either my ATA hard drive= failed to boot (it tried >> > >> >> to hand off to GRUB on my drive, but didn&#= 39;t get there), or it can't >> > >> >> find the option ROM of my video card, meani= ng no display. >> > >> >> >> > >> >> Now I want to try the other way, testing a = build with all changes >> > >> >> related to the problem backed out instead. = So besides the one I first >> > >> >> identified, what other related patches shou= ld I try backing out? >> > >> > >> > >> > >> > >> > Just go to the parent of the identified patch.= =C2=A0 As for the other symptoms you are seeing, I'd love to see logs w= ith the patches we identified so we can root cause. >> > >> > >> > >> > Thanks. >> > >> > >> > >> > -Aaron >> > >> > >> > >> >> >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Sh= aikh >> > >> >> <<a href=3D"mailto:furquan.m.shaikh@gmai= l.com" target=3D"_blank">furquan.m.shaikh(a)gmail.com</a>> wrote: >> > >> >> > >> > >> >> > Similar fix for i440x: <a href=3D"http= s://review.coreboot.org/c/coreboot/+/41368" rel=3D"noreferrer" target=3D"_b= lank">https://review.coreboot.org/c/coreboot/+/41368</a> >> > >> >> > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron= Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_blank">adurbin= @google.com</a>> wrote: >> > >> >> > > >> > >> >> > > i440x chipset is doing things in = the wrong way like sandybridge. I uploaded this fix for sandy: <a href=3D"h= ttps://review.coreboot.org/c/coreboot/+/41364" rel=3D"noreferrer" target=3D= "_blank">https://review.coreboot.org/c/coreboot/+/41364</a> We'll need = to do the equivalent for i440x. >> > >> >> > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM = Aaron Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_blank">ad= urbin(a)google.com</a>> wrote: >> > >> >> > >> >> > >> >> > >> OK. I'll take a look at y= our logs and see what's going on. The patch link I sent was based off o= f someone else's mainboard logs. >> > >> >> > >> >> > >> >> > >> On Wed, May 13, 2020 at 10:59= AM Keith Hui <<a href=3D"mailto:buurin@gmail.com" target=3D"_blank">buu= rin(a)gmail.com</a>> wrote: >> > >> >> > >>> >> > >> >> > >>> Hi Aaron, >> > >> >> > >>> >> > >> >> > >>> It didn't help. There= still a way out of whack entry in the coreboot >> > >> >> > >>> table and e820 entry endi= ng at 000003ffffffffff, which I think have >> > >> >> > >>> more to do than the 41363= 's scope. >> > >> >> > >>> >> > >> >> > >>> Keith >> > >> >> > >>> >> > >> >> > >>> On Wed, May 13, 2020 at 1= 2:24 PM Aaron Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_b= lank">adurbin(a)google.com</a>> wrote: >> > >> >> > >>> > >> > >> >> > >>> > I think the followin= g patch will fix things up: <a href=3D"https://review.coreboot.org/c/corebo= ot/+/41363" rel=3D"noreferrer" target=3D"_blank">https://review.coreboot.or= g/c/coreboot/+/41363</a> Please let me know. >> > >> >> > >>> > >> > >> >> > >>> > On Wed, May 13, 2020= at 8:43 AM Keith Hui <<a href=3D"mailto:buurin@gmail.com" target=3D"_bl= ank">buurin(a)gmail.com</a>> wrote: >> > >> >> > >>> >> >> > >> >> > >>> >> Thanks Furquan.<= br> >> > >> >> > >>> >> >> > >> >> > >>> >> Here are 3 logs.= Log 1 is at the commit just before the problem. Log 2 >> > >> >> > >>> >> is at the proble= m commit. Log 3 is at the current master, if that's >> > >> >> > >>> >> what you meant b= y ToT. >> > >> >> > >>> >> >> > >> >> > >>> >> I'm using Se= aBIOS 1.13.0, compiled once using the attached .config >> > >> >> > >>> >> before taking th= ese logs. All 3 runs are taken using the same SeaBIOS >> > >> >> > >>> >> binary. >> > >> >> > >>> >> >> > >> >> > >>> >> Then I recompile= d SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the >> > >> >> > >>> >> payload used in = run 3, and took an extra run. In this case the board >> > >> >> > >>> >> reset on its own= at "Scanning option roms", looping infinitely. >> > >> >> > >>> >> >> > >> >> > >>> >> Hope this helps<= br> >> > >> >> > >>> >> Keith >> > >> >> > >>> >> >> > >> >> > >>> >> On Wed, May 13, = 2020 at 7:38 AM Furquan Shaikh >> > >> >> > >>> >> <<a href=3D"m= ailto:furquan.m.shaikh@gmail.com" target=3D"_blank">furquan.m.shaikh(a)gmail.= com</a>> wrote: >> > >> >> > >>> >> > >> > >> >> > >>> >> > Thanks for = the report Keith! >> > >> >> > >>> >> > >> > >> >> > >>> >> > On Wed, May= 13, 2020 at 3:42 AM Paul Menzel <<a href=3D"mailto:pmenzel@molgen.mpg.d= e" target=3D"_blank">pmenzel(a)molgen.mpg.de</a>> wrote: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Dear K= eith, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Am 13.= 05.20 um 05:21 schrieb Keith Hui: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > I= am still refining the P2B family of boards, now including the >> > >> >> > >>> >> > > > i= nfamous P3B-F with an unusual appetite for hacks to make work. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > T= hat said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries<b= r> >> > >> >> > >>> >> > > > t= o relocate itself as part of its usual chores. Having just learned >> > >> >> > >>> >> > > > g= it bisect, I decided to try it out. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > I= t was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke >> > >> >> > >>> >> > > > m= y SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as >> > >> >> > >>> >> > > > P= 3B-F, but I still want to blame that, and probably the very next >> > >> >> > >>> >> > > > c= ommit as well, as they both deal with some very modern aspects of PCI >> > >> >> > >>> >> > > > t= hat well predates the 440BX. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > I= s there anything we can do to fix 3b02006afe? >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > I comm= ented in the change-set [1] to make the author and reviewers aware >> > >> >> > >>> >> > > of thi= s issue and referenced your list message, and ask to comment here. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Could = you please provide the debug log of coreboot and SeaBIOS? >> > >> >> > >>> >> > >> > >> >> > >>> >> > As Paul men= tioned, can you please provide the debug logs for coreboot >> > >> >> > >>> >> > and SeaBIOS= both with ToT coreboot and with HEAD set before the change >> > >> >> > >>> >> > 3b02006afe = where it does not hang? Thanks! >> > >> >> > >>> >> > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > M= eanwhile I ported the P3B-F board enable to flashrom [2], which got a >> > >> >> > >>> >> > > > h= eavy workout during this bisect, through vendor firmware and both >> > >> >> > >>> >> > > > g= ood and bad builds of coreboot. In all cases I can flash internal, no >> > >> >> > >>> >> > > > l= onger having to haul out my P2B-LS just to use it as a flasher. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > E= njoy this long overdue board enable. If it gets submitted, I'll >> > >> >> > >>> >> > > > r= etract the ramstage hack[3] doing the same as redundant. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Very n= ice! It=E2=80=99s always amazing, how after so many years, when the vendor<= br> >> > >> >> > >>> >> > > alread= y stopped supporting the device, the community still supports the >> > >> >> > >>> >> > > device= and improves the firmware showing that Free Software is the more >> > >> >> > >>> >> > > sustai= nable way. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Kind r= egards, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Paul<b= r> >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > [= 1] <a href=3D"https://review.coreboot.org/c/coreboot/+/39486" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/coreboot/+/39486</a><= br> >> > >> >> > >>> >> > > > [= 2] <a href=3D"https://review.coreboot.org/c/flashrom/+/41354" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/flashrom/+/41354</a><= br> >> > >> >> > >>> >> > > > [= 3] <a href=3D"https://review.coreboot.org/c/coreboot/+/41224" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/coreboot/+/41224</a><= br> >> > >> >> > >>> >> > > ______= _________________________________________ >> > >> >> > >>> >> > > corebo= ot mailing list -- <a href=3D"mailto:coreboot@coreboot.org" target=3D"_blan= k">coreboot(a)coreboot.org</a> >> > >> >> > >>> >> > > To uns= ubscribe send an email to <a href=3D"mailto:coreboot-leave@coreboot.org" ta= rget=3D"_blank">coreboot-leave(a)coreboot.org</a> >> > >> >> > >>> >> ________________= _______________________________ >> > >> >> > >>> >> coreboot mailing= list -- <a href=3D"mailto:coreboot@coreboot.org" target=3D"_blank">coreboo= t(a)coreboot.org</a> >> > >> >> > >>> >> To unsubscribe s= end an email to <a href=3D"mailto:coreboot-leave@coreboot.org" target=3D"_b= lank">coreboot-leave(a)coreboot.org</a> >> > _______________________________________________ >> > coreboot mailing list -- <a href=3D"mailto:coreboot@coreboot.= org" target=3D"_blank">coreboot(a)coreboot.org</a> >> > To unsubscribe send an email to <a href=3D"mailto:coreboot-le= ave(a)coreboot.org" target=3D"_blank">coreboot-leave(a)coreboot.org</a> </blockquote></div></div> --00000000000010123505a5a3957a-- ------------------------------ Subject: Digest Footer _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ End of coreboot Digest, Vol 183, Issue 21 ***************************************** ------------------------------ Subject: Digest Footer _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ End of coreboot Digest, Vol 183, Issue 25 *****************************************

1 0

Help unsubscribe
by Dan Collins 15 May '20

15 May '20

Help unsubscribe -----Original Message----- From: coreboot-request(a)coreboot.org <coreboot-request(a)coreboot.org> Sent: 14 May 2020 23:55 To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 183, Issue 21 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: Resource allocator: multiple boards regression (Keith Hui) 2. Re: Resource allocator: multiple boards regression (Aaron Durbin) ---------------------------------------------------------------------- Date: Thu, 14 May 2020 18:50:30 -0400 From: Keith Hui <buurin(a)gmail.com> Subject: [coreboot] Re: Resource allocator: multiple boards regression To: Aaron Durbin <adurbin(a)google.com> Cc: Mike Banon <mikebdp2(a)gmail.com>, Furquan Shaikh <furquan.m.shaikh(a)gmail.com>, coreboot <coreboot(a)coreboot.org> Message-ID: <CANTF=bTr=N8i-PZX0coB-uNE4FVXa8OEjk=CFT2rdrvhqxdjpQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi Aaron, You may want to check the QEMU-q35 target as well: Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 Emulation targets: "QEMU x86 q35/ich9" using payload TianoCore : FAIL : https://lava.9esec.io/r/3427 "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : https://lava.9esec.io/r/3426 "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/3425 "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS : https://lava.9esec.io/r/3424 Thanks Keith On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <adurbin(a)google.com> wrote: > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikebdp2(a)gmail.com> wrote: >> >> Unfortunately it seems a lot of boards are affected by this. A88XM-E >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at >> booting - and, when they do, no boot devices are available (virtual >> floppies too, for some reason) - except coreinfo/tint secondary >> payloads which became prone to freezing. I attach the A88XM-E logs >> I've been able to obtain with USB FT232H: >> >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot >> repo's revision where all the stuff works >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit >> got the boards broken for the first time >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log >> for coreboot's master top >> >> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2 >> EHCI Debug Port hook triggered". >> >> I hope these commits could be reverted before we figure out what's >> going on with them. Good thing we've noticed it fast enough. >> > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is fundamentally broken and at odds with all of the resource allocation flow. They worked previously because dynamic resources were being assigned using an algorithm that just assumed there weren't collisions, and that was done w/o all the necessary info required for making the proper decisions regarding dynamic resource allocation. > > I landed the other chipsets' fixes, but the amd chipset code is going to take a lot more to fix. Would you be willing to test patches as they are crafted? Given the largeness of the problem as well as the gnarly code that is the amd chipset code it's going to take some time so I think we do need to revert the allocator changes until we can do some house keeping. > > -Aaron >> >> Best regards, >> Mike Banon >> >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <buurin(a)gmail.com> wrote: >> > >> > Hi guys, >> > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. >> > >> > Turns out I have to back out all four of Furquan's patches >> > (CB:39486~39489) for my board to boot normally again. >> > >> > Thoughts? >> > >> > I'll now get a log with everything in at SPEW. >> > >> > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <adurbin(a)google.com> wrote: >> > > >> > > Keith, is it possible to have the console log level set to SPEW? I'm not seeing the full logs to piece it all together. >> > > >> > > Allocating resources... >> > > Reading resources... >> > > Setting RAM size to 768 MB >> > > PNP: 03f0.8 missing read_resources >> > > Done reading resources. >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) >> > > Resource ranges: >> > > Base: 1000, Size: d000, Tag: 100 >> > > Base: f000, Size: 1000, Tag: 100 >> > > Resource ranges: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > Resource ranges: >> > > Base: 10000000, Size: 8000000, Tag: 1200 >> > > Resource ranges: >> > > Base: 18000000, Size: 1100000, Tag: 200 >> > > >> > > This is the memory address space: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > >> > > Those are valid ranges to choose dynamic resources from. >> > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size 0x10000000 gran 0x1c prefmem >> > > >> > > I see 'Setting RAM size to 768 MB' which means I would expect to see a hole in the ranges representing 768MiB. >> > > >> > > that would be bad. I don't know what commit '31ab7de51a' is, but it might not contain the CB:41368. Having SPEW logs would be helpful. >> > > >> > > Also, what mainboard Kconfig are you selecting for p3bf? src/mainboard/asus/p2b ? >> > > >> > > >> > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >> (Temporarily leaving the list out) >> > >> >> > >> Hi Aaron, >> > >> >> > >> Here is a log with everything including CB:41368 included. I'll get >> > >> this log out to you first, while I try a build with all problem >> > >> commits left out. >> > >> >> > >> Thanks >> > >> Keith >> > >> >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> >> > >> >> Hi guys, >> > >> >> >> > >> >> I tested these fixes on my board, and I have to say there's still >> > >> >> something wrong. They did address the hang or reset in SeaBIOS I first >> > >> >> described, but now either my ATA hard drive failed to boot (it tried >> > >> >> to hand off to GRUB on my drive, but didn't get there), or it can't >> > >> >> find the option ROM of my video card, meaning no display. >> > >> >> >> > >> >> Now I want to try the other way, testing a build with all changes >> > >> >> related to the problem backed out instead. So besides the one I first >> > >> >> identified, what other related patches should I try backing out? >> > >> > >> > >> > >> > >> > Just go to the parent of the identified patch. As for the other symptoms you are seeing, I'd love to see logs with the patches we identified so we can root cause. >> > >> > >> > >> > Thanks. >> > >> > >> > >> > -Aaron >> > >> > >> > >> >> >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh >> > >> >> <furquan.m.shaikh(a)gmail.com> wrote: >> > >> >> > >> > >> >> > Similar fix for i440x: https://review.coreboot.org/c/coreboot/+/41368 >> > >> >> > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > > >> > >> >> > > i440x chipset is doing things in the wrong way like sandybridge. I uploaded this fix for sandy: https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the equivalent for i440x. >> > >> >> > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > >> >> > >> >> > >> OK. I'll take a look at your logs and see what's going on. The patch link I sent was based off of someone else's mainboard logs. >> > >> >> > >> >> > >> >> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >>> >> > >> >> > >>> Hi Aaron, >> > >> >> > >>> >> > >> >> > >>> It didn't help. There still a way out of whack entry in the coreboot >> > >> >> > >>> table and e820 entry ending at 000003ffffffffff, which I think have >> > >> >> > >>> more to do than the 41363's scope. >> > >> >> > >>> >> > >> >> > >>> Keith >> > >> >> > >>> >> > >> >> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin <adurbin(a)google.com> wrote: >> > >> >> > >>> > >> > >> >> > >>> > I think the following patch will fix things up: https://review.coreboot.org/c/coreboot/+/41363 Please let me know. >> > >> >> > >>> > >> > >> >> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui <buurin(a)gmail.com> wrote: >> > >> >> > >>> >> >> > >> >> > >>> >> Thanks Furquan. >> > >> >> > >>> >> >> > >> >> > >>> >> Here are 3 logs. Log 1 is at the commit just before the problem. Log 2 >> > >> >> > >>> >> is at the problem commit. Log 3 is at the current master, if that's >> > >> >> > >>> >> what you meant by ToT. >> > >> >> > >>> >> >> > >> >> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the attached .config >> > >> >> > >>> >> before taking these logs. All 3 runs are taken using the same SeaBIOS >> > >> >> > >>> >> binary. >> > >> >> > >>> >> >> > >> >> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the >> > >> >> > >>> >> payload used in run 3, and took an extra run. In this case the board >> > >> >> > >>> >> reset on its own at "Scanning option roms", looping infinitely. >> > >> >> > >>> >> >> > >> >> > >>> >> Hope this helps >> > >> >> > >>> >> Keith >> > >> >> > >>> >> >> > >> >> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh >> > >> >> > >>> >> <furquan.m.shaikh(a)gmail.com> wrote: >> > >> >> > >>> >> > >> > >> >> > >>> >> > Thanks for the report Keith! >> > >> >> > >>> >> > >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Dear Keith, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > I am still refining the P2B family of boards, now including the >> > >> >> > >>> >> > > > infamous P3B-F with an unusual appetite for hacks to make work. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > That said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries >> > >> >> > >>> >> > > > to relocate itself as part of its usual chores. Having just learned >> > >> >> > >>> >> > > > git bisect, I decided to try it out. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > It was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke >> > >> >> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as >> > >> >> > >>> >> > > > P3B-F, but I still want to blame that, and probably the very next >> > >> >> > >>> >> > > > commit as well, as they both deal with some very modern aspects of PCI >> > >> >> > >>> >> > > > that well predates the 440BX. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Is there anything we can do to fix 3b02006afe? >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > I commented in the change-set [1] to make the author and reviewers aware >> > >> >> > >>> >> > > of this issue and referenced your list message, and ask to comment here. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Could you please provide the debug log of coreboot and SeaBIOS? >> > >> >> > >>> >> > >> > >> >> > >>> >> > As Paul mentioned, can you please provide the debug logs for coreboot >> > >> >> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD set before the change >> > >> >> > >>> >> > 3b02006afe where it does not hang? Thanks! >> > >> >> > >>> >> > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > Meanwhile I ported the P3B-F board enable to flashrom [2], which got a >> > >> >> > >>> >> > > > heavy workout during this bisect, through vendor firmware and both >> > >> >> > >>> >> > > > good and bad builds of coreboot. In all cases I can flash internal, no >> > >> >> > >>> >> > > > longer having to haul out my P2B-LS just to use it as a flasher. >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Enjoy this long overdue board enable. If it gets submitted, I'll >> > >> >> > >>> >> > > > retract the ramstage hack[3] doing the same as redundant. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Very nice! It’s always amazing, how after so many years, when the vendor >> > >> >> > >>> >> > > already stopped supporting the device, the community still supports the >> > >> >> > >>> >> > > device and improves the firmware showing that Free Software is the more >> > >> >> > >>> >> > > sustainable way. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Kind regards, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Paul >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > [1] https://review.coreboot.org/c/coreboot/+/39486 >> > >> >> > >>> >> > > > [2] https://review.coreboot.org/c/flashrom/+/41354 >> > >> >> > >>> >> > > > [3] https://review.coreboot.org/c/coreboot/+/41224 >> > >> >> > >>> >> > > _______________________________________________ >> > >> >> > >>> >> > > coreboot mailing list -- coreboot(a)coreboot.org >> > >> >> > >>> >> > > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >> >> > >>> >> _______________________________________________ >> > >> >> > >>> >> coreboot mailing list -- coreboot(a)coreboot.org >> > >> >> > >>> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ Date: Thu, 14 May 2020 16:54:29 -0600 From: Aaron Durbin <adurbin(a)google.com> Subject: [coreboot] Re: Resource allocator: multiple boards regression To: Keith Hui <buurin(a)gmail.com> Cc: Mike Banon <mikebdp2(a)gmail.com>, Furquan Shaikh <furquan.m.shaikh(a)gmail.com>, coreboot <coreboot(a)coreboot.org> Message-ID: <CAE2855tBax_piH9+dGeFeu3dWHF6+VQkZ6oWPBCL2hCNhaDFOw(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="00000000000010123505a5a3957a" --00000000000010123505a5a3957a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2020 at 4:44 PM Keith Hui <buurin(a)gmail.com> wrote: > Hi Aaron, > > You may want to check the QEMU-q35 target as well: > > Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 > Emulation targets: > "QEMU x86 q35/ich9" using payload TianoCore : FAIL : > https://lava.9esec.io/r/3427 > "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : > https://lava.9esec.io/r/3426 > "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : > https://lava.9esec.io/r/3425 > "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS : > https://lava.9esec.io/r/3424 Ya. Those are fixed from the patches that fixed your device, Keith. > > > Thanks > Keith > > On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <adurbin(a)google.com> wrote: > > > > > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikebdp2(a)gmail.com> wrote: > >> > >> Unfortunately it seems a lot of boards are affected by this. A88XM-E > >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at > >> booting - and, when they do, no boot devices are available (virtual > >> floppies too, for some reason) - except coreinfo/tint secondary > >> payloads which became prone to freezing. I attach the A88XM-E logs > >> I've been able to obtain with USB FT232H: > >> > >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot > >> repo's revision where all the stuff works > >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit > >> got the boards broken for the first time > >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log > >> for coreboot's master top > >> > >> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2 > >> EHCI Debug Port hook triggered". > >> > >> I hope these commits could be reverted before we figure out what's > >> going on with them. Good thing we've noticed it fast enough. > >> > > > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is > fundamentally broken and at odds with all of the resource allocation flow= . > They worked previously because dynamic resources were being assigned usin= g > an algorithm that just assumed there weren't collisions, and that was don= e > w/o all the necessary info required for making the proper decisions > regarding dynamic resource allocation. > > > > I landed the other chipsets' fixes, but the amd chipset code is going t= o > take a lot more to fix. Would you be willing to test patches as they are > crafted? Given the largeness of the problem as well as the gnarly code th= at > is the amd chipset code it's going to take some time so I think we do nee= d > to revert the allocator changes until we can do some house keeping. > > > > -Aaron > >> > >> Best regards, > >> Mike Banon > >> > >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <buurin(a)gmail.com> wrote: > >> > > >> > Hi guys, > >> > > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. > >> > > >> > Turns out I have to back out all four of Furquan's patches > >> > (CB:39486~39489) for my board to boot normally again. > >> > > >> > Thoughts? > >> > > >> > I'll now get a log with everything in at SPEW. > >> > > >> > > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <adurbin(a)google.com> > wrote: > >> > > > >> > > Keith, is it possible to have the console log level set to SPEW? > I'm not seeing the full logs to piece it all together. > >> > > > >> > > Allocating resources... > >> > > Reading resources... > >> > > Setting RAM size to 768 MB > >> > > PNP: 03f0.8 missing read_resources > >> > > Done reading resources. > >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering requirements) > >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating resources) > >> > > Resource ranges: > >> > > Base: 1000, Size: d000, Tag: 100 > >> > > Base: f000, Size: 1000, Tag: 100 > >> > > Resource ranges: > >> > > Base: 0, Size: ff800000, Tag: 200 > >> > > Base: 100000000, Size: f00000000, Tag: 100200 > >> > > Resource ranges: > >> > > Base: 10000000, Size: 8000000, Tag: 1200 > >> > > Resource ranges: > >> > > Base: 18000000, Size: 1100000, Tag: 200 > >> > > > >> > > This is the memory address space: > >> > > Base: 0, Size: ff800000, Tag: 200 > >> > > Base: 100000000, Size: f00000000, Tag: 100200 > >> > > > >> > > Those are valid ranges to choose dynamic resources from. > >> > > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size 0x10000000 > gran 0x1c prefmem > >> > > > >> > > I see 'Setting RAM size to 768 MB' which means I would expect to > see a hole in the ranges representing 768MiB. > >> > > > >> > > that would be bad. I don't know what commit '31ab7de51a' is, but i= t > might not contain the CB:41368. Having SPEW logs would be helpful. > >> > > > >> > > Also, what mainboard Kconfig are you selecting for p3bf? > src/mainboard/asus/p2b ? > >> > > > >> > > > >> > > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <buurin(a)gmail.com> > wrote: > >> > >> > >> > >> (Temporarily leaving the list out) > >> > >> > >> > >> Hi Aaron, > >> > >> > >> > >> Here is a log with everything including CB:41368 included. I'll g= et > >> > >> this log out to you first, while I try a build with all problem > >> > >> commits left out. > >> > >> > >> > >> Thanks > >> > >> Keith > >> > >> > >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <adurbin(a)google.com= > > wrote: > >> > >> > > >> > >> > > >> > >> > > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buurin(a)gmail.com> > wrote: > >> > >> >> > >> > >> >> Hi guys, > >> > >> >> > >> > >> >> I tested these fixes on my board, and I have to say there's > still > >> > >> >> something wrong. They did address the hang or reset in SeaBIOS > I first > >> > >> >> described, but now either my ATA hard drive failed to boot (it > tried > >> > >> >> to hand off to GRUB on my drive, but didn't get there), or it > can't > >> > >> >> find the option ROM of my video card, meaning no display. > >> > >> >> > >> > >> >> Now I want to try the other way, testing a build with all > changes > >> > >> >> related to the problem backed out instead. So besides the one = I > first > >> > >> >> identified, what other related patches should I try backing ou= t? > >> > >> > > >> > >> > > >> > >> > Just go to the parent of the identified patch. As for the othe= r > symptoms you are seeing, I'd love to see logs with the patches we > identified so we can root cause. > >> > >> > > >> > >> > Thanks. > >> > >> > > >> > >> > -Aaron > >> > >> > > >> > >> >> > >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Shaikh > >> > >> >> <furquan.m.shaikh(a)gmail.com> wrote: > >> > >> >> > > >> > >> >> > Similar fix for i440x: > https://review.coreboot.org/c/coreboot/+/41368 > >> > >> >> > > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > > > >> > >> >> > > i440x chipset is doing things in the wrong way like > sandybridge. I uploaded this fix for sandy: > https://review.coreboot.org/c/coreboot/+/41364 We'll need to do the > equivalent for i440x. > >> > >> >> > > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > >> > >> > >> >> > >> OK. I'll take a look at your logs and see what's going on= . > The patch link I sent was based off of someone else's mainboard logs. > >> > >> >> > >> > >> > >> >> > >> On Wed, May 13, 2020 at 10:59 AM Keith Hui < > buurin(a)gmail.com> wrote: > >> > >> >> > >>> > >> > >> >> > >>> Hi Aaron, > >> > >> >> > >>> > >> > >> >> > >>> It didn't help. There still a way out of whack entry in > the coreboot > >> > >> >> > >>> table and e820 entry ending at 000003ffffffffff, which I > think have > >> > >> >> > >>> more to do than the 41363's scope. > >> > >> >> > >>> > >> > >> >> > >>> Keith > >> > >> >> > >>> > >> > >> >> > >>> On Wed, May 13, 2020 at 12:24 PM Aaron Durbin < > adurbin(a)google.com> wrote: > >> > >> >> > >>> > > >> > >> >> > >>> > I think the following patch will fix things up: > https://review.coreboot.org/c/coreboot/+/41363 Please let me know. > >> > >> >> > >>> > > >> > >> >> > >>> > On Wed, May 13, 2020 at 8:43 AM Keith Hui < > buurin(a)gmail.com> wrote: > >> > >> >> > >>> >> > >> > >> >> > >>> >> Thanks Furquan. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Here are 3 logs. Log 1 is at the commit just before > the problem. Log 2 > >> > >> >> > >>> >> is at the problem commit. Log 3 is at the current > master, if that's > >> > >> >> > >>> >> what you meant by ToT. > >> > >> >> > >>> >> > >> > >> >> > >>> >> I'm using SeaBIOS 1.13.0, compiled once using the > attached .config > >> > >> >> > >>> >> before taking these logs. All 3 runs are taken using > the same SeaBIOS > >> > >> >> > >>> >> binary. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Then I recompiled SeaBIOS with CONFIG_RELOCATE_INIT > off, replaced the > >> > >> >> > >>> >> payload used in run 3, and took an extra run. In this > case the board > >> > >> >> > >>> >> reset on its own at "Scanning option roms", looping > infinitely. > >> > >> >> > >>> >> > >> > >> >> > >>> >> Hope this helps > >> > >> >> > >>> >> Keith > >> > >> >> > >>> >> > >> > >> >> > >>> >> On Wed, May 13, 2020 at 7:38 AM Furquan Shaikh > >> > >> >> > >>> >> <furquan.m.shaikh(a)gmail.com> wrote: > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > Thanks for the report Keith! > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel < > pmenzel(a)molgen.mpg.de> wrote: > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Dear Keith, > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Am 13.05.20 um 05:21 schrieb Keith Hui: > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > I am still refining the P2B family of boards, > now including the > >> > >> >> > >>> >> > > > infamous P3B-F with an unusual appetite for > hacks to make work. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > That said, I'm now finding that, on P3B-F, > SeaBIOS hangs when it tries > >> > >> >> > >>> >> > > > to relocate itself as part of its usual chores. > Having just learned > >> > >> >> > >>> >> > > > git bisect, I decided to try it out. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > It was commit > 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke > >> > >> >> > >>> >> > > > my SeaBIOS. It doesn't affect my newer toy the > P8Z77-M as much as > >> > >> >> > >>> >> > > > P3B-F, but I still want to blame that, and > probably the very next > >> > >> >> > >>> >> > > > commit as well, as they both deal with some ver= y > modern aspects of PCI > >> > >> >> > >>> >> > > > that well predates the 440BX. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > Is there anything we can do to fix 3b02006afe? > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > I commented in the change-set [1] to make the > author and reviewers aware > >> > >> >> > >>> >> > > of this issue and referenced your list message, > and ask to comment here. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Could you please provide the debug log of coreboo= t > and SeaBIOS? > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > As Paul mentioned, can you please provide the debug > logs for coreboot > >> > >> >> > >>> >> > and SeaBIOS both with ToT coreboot and with HEAD se= t > before the change > >> > >> >> > >>> >> > 3b02006afe where it does not hang? Thanks! > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > Meanwhile I ported the P3B-F board enable to > flashrom [2], which got a > >> > >> >> > >>> >> > > > heavy workout during this bisect, through vendo= r > firmware and both > >> > >> >> > >>> >> > > > good and bad builds of coreboot. In all cases I > can flash internal, no > >> > >> >> > >>> >> > > > longer having to haul out my P2B-LS just to use > it as a flasher. > >> > >> >> > >>> >> > > > > >> > >> >> > >>> >> > > > Enjoy this long overdue board enable. If it get= s > submitted, I'll > >> > >> >> > >>> >> > > > retract the ramstage hack[3] doing the same as > redundant. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Very nice! It=E2=80=99s always amazing, how after= so many > years, when the vendor > >> > >> >> > >>> >> > > already stopped supporting the device, the > community still supports the > >> > >> >> > >>> >> > > device and improves the firmware showing that Fre= e > Software is the more > >> > >> >> > >>> >> > > sustainable way. > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Kind regards, > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > Paul > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > >> > >> >> > >>> >> > > > [1] > https://review.coreboot.org/c/coreboot/+/39486 > >> > >> >> > >>> >> > > > [2] > https://review.coreboot.org/c/flashrom/+/41354 > >> > >> >> > >>> >> > > > [3] > https://review.coreboot.org/c/coreboot/+/41224 > >> > >> >> > >>> >> > > _______________________________________________ > >> > >> >> > >>> >> > > coreboot mailing list -- coreboot(a)coreboot.org > >> > >> >> > >>> >> > > To unsubscribe send an email to > coreboot-leave(a)coreboot.org > >> > >> >> > >>> >> _______________________________________________ > >> > >> >> > >>> >> coreboot mailing list -- coreboot(a)coreboot.org > >> > >> >> > >>> >> To unsubscribe send an email to > coreboot-leave(a)coreboot.org > >> > _______________________________________________ > >> > coreboot mailing list -- coreboot(a)coreboot.org > >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org > --00000000000010123505a5a3957a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif"> </div></div> <div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 14, 2020 at 4:44 PM Keith= Hui <<a href=3D"mailto:buurin@gmail.com">buurin(a)gmail.com</a>> wrote= : </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Aaron, You may want to check the QEMU-q35 target as well: Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4 Emulation targets: "QEMU x86 q35/ich9" using payload TianoCore : FAIL : <a href=3D"https://lava.9esec.io/r/3427" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3427</a> "QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : <a href=3D"htt= ps://lava.9esec.io/r/3426" rel=3D"noreferrer" target=3D"_blank">https://lav= a.9esec.io/r/3426</a> "QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS : <a href=3D"https://lava.9esec.io/r/3425" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3425</a> "QEMU AArch64" using payload LinuxBoot_u-root_kexec : SUCCESS :<b= r> <a href=3D"https://lava.9esec.io/r/3424" rel=3D"noreferrer" target=3D"_blan= k">https://lava.9esec.io/r/3424</a></blockquote><div> </div><div class= =3D"gmail_default" style=3D"font-family:tahoma,sans-serif">Ya. Those are fi= xed from the patches that fixed your device, Keith.</div><div class=3D"gmai= l_default" style=3D"font-family:tahoma,sans-serif"></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> Thanks Keith On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <<a href=3D"mailto:adurbin@= google.com" target=3D"_blank">adurbin(a)google.com</a>> wrote: > > > > On Thu, May 14, 2020 at 2:46 PM Mike Banon <<a href=3D"mailto:mikeb= dp2(a)gmail.com" target=3D"_blank">mikebdp2(a)gmail.com</a>> wrote: >> >> Unfortunately it seems a lot of boards are affected by this. A88XM= -E >> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed= at >> booting - and, when they do, no boot devices are available (virtua= l >> floppies too, for some reason) - except coreinfo/tint secondary<br= > >> payloads which became prone to freezing. I attach the A88XM-E logs= >> I've been able to obtain with USB FT232H: >> >> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot= >> repo's revision where all the stuff works >> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this comm= it >> got the boards broken for the first time >> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a= log >> for coreboot's master top >> >> For some reason logs for 2) and 3) always stop after "PCI: 00= :12.2 >> EHCI Debug Port hook triggered". >> >> I hope these commits could be reverted before we figure out what&#= 39;s >> going on with them. Good thing we've noticed it fast enough.<b= r> >> > > Thanks, Mike. The amd chipset code (all of it from what I can tell) is= fundamentally broken and at odds with all of the resource allocation flow.= They worked previously because dynamic resources were being assigned using= an algorithm that just assumed there weren't collisions, and that was = done w/o all the necessary info required for making the proper decisions re= garding dynamic resource allocation. > > I landed the other chipsets' fixes, but the amd chipset code is go= ing to take a lot more to fix. Would you be willing to test patches as they= are crafted? Given the largeness of the problem as well as the gnarly code= that is the amd chipset code it's going to take some time so I think w= e do need to revert the allocator changes until we can do some house keepin= g. > > -Aaron >> >> Best regards, >> Mike Banon >> >> On Thu, May 14, 2020 at 8:47 PM Keith Hui <<a href=3D"mailto:bu= urin(a)gmail.com" target=3D"_blank">buurin(a)gmail.com</a>> wrote: >> > >> > Hi guys, >> > >> > 31ab7de51a is CB:41368, cherry picked into my local repo. >> > >> > Turns out I have to back out all four of Furquan's patche= s >> > (CB:39486~39489) for my board to boot normally again. >> > >> > Thoughts? >> > >> > I'll now get a log with everything in at SPEW. >> > >> > >> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <<a href=3D"m= ailto:adurbin@google.com" target=3D"_blank">adurbin(a)google.com</a>> wrot= e: >> > > >> > > Keith, is it possible to have the console log level set = to SPEW? I'm not seeing the full logs to piece it all together. >> > > >> > > Allocating resources... >> > > Reading resources... >> > > Setting RAM size to 768 MB >> > > PNP: 03f0.8 missing read_resources >> > > Done reading resources. >> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering req= uirements) >> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating re= sources) >> > > Resource ranges: >> > > Base: 1000, Size: d000, Tag: 100 >> > > Base: f000, Size: 1000, Tag: 100 >> > > Resource ranges: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > Resource ranges: >> > > Base: 10000000, Size: 8000000, Tag: 1200 >> > > Resource ranges: >> > > Base: 18000000, Size: 1100000, Tag: 200 >> > > >> > > This is the memory address space: >> > > Base: 0, Size: ff800000, Tag: 200 >> > > Base: 100000000, Size: f00000000, Tag: 100200 >> > > >> > > Those are valid ranges to choose dynamic resources from.= >> > > >> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size= 0x10000000 gran 0x1c prefmem >> > > >> > > I see 'Setting RAM size to 768 MB' which means I= would expect to see a hole in the ranges representing 768MiB. >> > > >> > > that would be bad. I don't know what commit '31a= b7de51a' is, but it might not contain the CB:41368. Having SPEW logs wo= uld be helpful. >> > > >> > > Also, what mainboard Kconfig are you selecting for p3bf?= src/mainboard/asus/p2b ? >> > > >> > > >> > > >> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <<a href= =3D"mailto:buurin@gmail.com" target=3D"_blank">buurin(a)gmail.com</a>> wro= te: >> > >> >> > >> (Temporarily leaving the list out) >> > >> >> > >> Hi Aaron, >> > >> >> > >> Here is a log with everything including CB:41368 inc= luded. I'll get >> > >> this log out to you first, while I try a build with = all problem >> > >> commits left out. >> > >> >> > >> Thanks >> > >> Keith >> > >> >> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <<a= href=3D"mailto:adurbin@google.com" target=3D"_blank">adurbin(a)google.com</a= >> wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <= <a href=3D"mailto:buurin@gmail.com" target=3D"_blank">buurin(a)gmail.com</a>&= gt; wrote: >> > >> >> >> > >> >> Hi guys, >> > >> >> >> > >> >> I tested these fixes on my board, and I hav= e to say there's still >> > >> >> something wrong. They did address the hang = or reset in SeaBIOS I first >> > >> >> described, but now either my ATA hard drive= failed to boot (it tried >> > >> >> to hand off to GRUB on my drive, but didn&#= 39;t get there), or it can't >> > >> >> find the option ROM of my video card, meani= ng no display. >> > >> >> >> > >> >> Now I want to try the other way, testing a = build with all changes >> > >> >> related to the problem backed out instead. = So besides the one I first >> > >> >> identified, what other related patches shou= ld I try backing out? >> > >> > >> > >> > >> > >> > Just go to the parent of the identified patch.= =C2=A0 As for the other symptoms you are seeing, I'd love to see logs w= ith the patches we identified so we can root cause. >> > >> > >> > >> > Thanks. >> > >> > >> > >> > -Aaron >> > >> > >> > >> >> >> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Sh= aikh >> > >> >> <<a href=3D"mailto:furquan.m.shaikh@gmai= l.com" target=3D"_blank">furquan.m.shaikh(a)gmail.com</a>> wrote: >> > >> >> > >> > >> >> > Similar fix for i440x: <a href=3D"http= s://review.coreboot.org/c/coreboot/+/41368" rel=3D"noreferrer" target=3D"_b= lank">https://review.coreboot.org/c/coreboot/+/41368</a> >> > >> >> > >> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron= Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_blank">adurbin= @google.com</a>> wrote: >> > >> >> > > >> > >> >> > > i440x chipset is doing things in = the wrong way like sandybridge. I uploaded this fix for sandy: <a href=3D"h= ttps://review.coreboot.org/c/coreboot/+/41364" rel=3D"noreferrer" target=3D= "_blank">https://review.coreboot.org/c/coreboot/+/41364</a> We'll need = to do the equivalent for i440x. >> > >> >> > > >> > >> >> > > On Wed, May 13, 2020 at 11:13 AM = Aaron Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_blank">ad= urbin(a)google.com</a>> wrote: >> > >> >> > >> >> > >> >> > >> OK. I'll take a look at y= our logs and see what's going on. The patch link I sent was based off o= f someone else's mainboard logs. >> > >> >> > >> >> > >> >> > >> On Wed, May 13, 2020 at 10:59= AM Keith Hui <<a href=3D"mailto:buurin@gmail.com" target=3D"_blank">buu= rin(a)gmail.com</a>> wrote: >> > >> >> > >>> >> > >> >> > >>> Hi Aaron, >> > >> >> > >>> >> > >> >> > >>> It didn't help. There= still a way out of whack entry in the coreboot >> > >> >> > >>> table and e820 entry endi= ng at 000003ffffffffff, which I think have >> > >> >> > >>> more to do than the 41363= 's scope. >> > >> >> > >>> >> > >> >> > >>> Keith >> > >> >> > >>> >> > >> >> > >>> On Wed, May 13, 2020 at 1= 2:24 PM Aaron Durbin <<a href=3D"mailto:adurbin@google.com" target=3D"_b= lank">adurbin(a)google.com</a>> wrote: >> > >> >> > >>> > >> > >> >> > >>> > I think the followin= g patch will fix things up: <a href=3D"https://review.coreboot.org/c/corebo= ot/+/41363" rel=3D"noreferrer" target=3D"_blank">https://review.coreboot.or= g/c/coreboot/+/41363</a> Please let me know. >> > >> >> > >>> > >> > >> >> > >>> > On Wed, May 13, 2020= at 8:43 AM Keith Hui <<a href=3D"mailto:buurin@gmail.com" target=3D"_bl= ank">buurin(a)gmail.com</a>> wrote: >> > >> >> > >>> >> >> > >> >> > >>> >> Thanks Furquan.<= br> >> > >> >> > >>> >> >> > >> >> > >>> >> Here are 3 logs.= Log 1 is at the commit just before the problem. Log 2 >> > >> >> > >>> >> is at the proble= m commit. Log 3 is at the current master, if that's >> > >> >> > >>> >> what you meant b= y ToT. >> > >> >> > >>> >> >> > >> >> > >>> >> I'm using Se= aBIOS 1.13.0, compiled once using the attached .config >> > >> >> > >>> >> before taking th= ese logs. All 3 runs are taken using the same SeaBIOS >> > >> >> > >>> >> binary. >> > >> >> > >>> >> >> > >> >> > >>> >> Then I recompile= d SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the >> > >> >> > >>> >> payload used in = run 3, and took an extra run. In this case the board >> > >> >> > >>> >> reset on its own= at "Scanning option roms", looping infinitely. >> > >> >> > >>> >> >> > >> >> > >>> >> Hope this helps<= br> >> > >> >> > >>> >> Keith >> > >> >> > >>> >> >> > >> >> > >>> >> On Wed, May 13, = 2020 at 7:38 AM Furquan Shaikh >> > >> >> > >>> >> <<a href=3D"m= ailto:furquan.m.shaikh@gmail.com" target=3D"_blank">furquan.m.shaikh(a)gmail.= com</a>> wrote: >> > >> >> > >>> >> > >> > >> >> > >>> >> > Thanks for = the report Keith! >> > >> >> > >>> >> > >> > >> >> > >>> >> > On Wed, May= 13, 2020 at 3:42 AM Paul Menzel <<a href=3D"mailto:pmenzel@molgen.mpg.d= e" target=3D"_blank">pmenzel(a)molgen.mpg.de</a>> wrote: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Dear K= eith, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Am 13.= 05.20 um 05:21 schrieb Keith Hui: >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > I= am still refining the P2B family of boards, now including the >> > >> >> > >>> >> > > > i= nfamous P3B-F with an unusual appetite for hacks to make work. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > T= hat said, I'm now finding that, on P3B-F, SeaBIOS hangs when it tries<b= r> >> > >> >> > >>> >> > > > t= o relocate itself as part of its usual chores. Having just learned >> > >> >> > >>> >> > > > g= it bisect, I decided to try it out. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > I= t was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke >> > >> >> > >>> >> > > > m= y SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as >> > >> >> > >>> >> > > > P= 3B-F, but I still want to blame that, and probably the very next >> > >> >> > >>> >> > > > c= ommit as well, as they both deal with some very modern aspects of PCI >> > >> >> > >>> >> > > > t= hat well predates the 440BX. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > I= s there anything we can do to fix 3b02006afe? >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > I comm= ented in the change-set [1] to make the author and reviewers aware >> > >> >> > >>> >> > > of thi= s issue and referenced your list message, and ask to comment here. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Could = you please provide the debug log of coreboot and SeaBIOS? >> > >> >> > >>> >> > >> > >> >> > >>> >> > As Paul men= tioned, can you please provide the debug logs for coreboot >> > >> >> > >>> >> > and SeaBIOS= both with ToT coreboot and with HEAD set before the change >> > >> >> > >>> >> > 3b02006afe = where it does not hang? Thanks! >> > >> >> > >>> >> > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > M= eanwhile I ported the P3B-F board enable to flashrom [2], which got a >> > >> >> > >>> >> > > > h= eavy workout during this bisect, through vendor firmware and both >> > >> >> > >>> >> > > > g= ood and bad builds of coreboot. In all cases I can flash internal, no >> > >> >> > >>> >> > > > l= onger having to haul out my P2B-LS just to use it as a flasher. >> > >> >> > >>> >> > > ><b= r> >> > >> >> > >>> >> > > > E= njoy this long overdue board enable. If it gets submitted, I'll >> > >> >> > >>> >> > > > r= etract the ramstage hack[3] doing the same as redundant. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Very n= ice! It=E2=80=99s always amazing, how after so many years, when the vendor<= br> >> > >> >> > >>> >> > > alread= y stopped supporting the device, the community still supports the >> > >> >> > >>> >> > > device= and improves the firmware showing that Free Software is the more >> > >> >> > >>> >> > > sustai= nable way. >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Kind r= egards, >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > Paul<b= r> >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > >> > >> >> > >>> >> > > > [= 1] <a href=3D"https://review.coreboot.org/c/coreboot/+/39486" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/coreboot/+/39486</a><= br> >> > >> >> > >>> >> > > > [= 2] <a href=3D"https://review.coreboot.org/c/flashrom/+/41354" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/flashrom/+/41354</a><= br> >> > >> >> > >>> >> > > > [= 3] <a href=3D"https://review.coreboot.org/c/coreboot/+/41224" rel=3D"norefe= rrer" target=3D"_blank">https://review.coreboot.org/c/coreboot/+/41224</a><= br> >> > >> >> > >>> >> > > ______= _________________________________________ >> > >> >> > >>> >> > > corebo= ot mailing list -- <a href=3D"mailto:coreboot@coreboot.org" target=3D"_blan= k">coreboot(a)coreboot.org</a> >> > >> >> > >>> >> > > To uns= ubscribe send an email to <a href=3D"mailto:coreboot-leave@coreboot.org" ta= rget=3D"_blank">coreboot-leave(a)coreboot.org</a> >> > >> >> > >>> >> ________________= _______________________________ >> > >> >> > >>> >> coreboot mailing= list -- <a href=3D"mailto:coreboot@coreboot.org" target=3D"_blank">coreboo= t(a)coreboot.org</a> >> > >> >> > >>> >> To unsubscribe s= end an email to <a href=3D"mailto:coreboot-leave@coreboot.org" target=3D"_b= lank">coreboot-leave(a)coreboot.org</a> >> > _______________________________________________ >> > coreboot mailing list -- <a href=3D"mailto:coreboot@coreboot.= org" target=3D"_blank">coreboot(a)coreboot.org</a> >> > To unsubscribe send an email to <a href=3D"mailto:coreboot-le= ave(a)coreboot.org" target=3D"_blank">coreboot-leave(a)coreboot.org</a> </blockquote></div></div> --00000000000010123505a5a3957a-- ------------------------------ Subject: Digest Footer _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ End of coreboot Digest, Vol 183, Issue 21 *****************************************

1 0

Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()
by Keith Hui 14 May '20

14 May '20

Hi Aaron, Here are two more logs at SPEW. Old log is a separate branch where I reverted all the problem commits; new log has everything. Thanks Keith

3 5

qemu-i440fx regression: No graphics in payload
by Paul Menzel 14 May '20

14 May '20

Dear Furquan, dear Aaron, Commit 3b02006afe (device: Enable resource allocator to use multiple ranges) [1] also breaks the qemu-i440fx, that SeaBIOS does not show any graphics. Please find the logs attached. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/39486

1 1

[HEADS-UP] Current master broken
by Paul Menzel 14 May '20

14 May '20

Dear coreboot users, Several users reported regressions with commit 3b02006afe (device: Enable resource allocator to use multiple ranges) [1] on their devices. $ git describe 3b02006afe8a85477dafa1bd149f1f0dba02afc7 4.12-9-g3b02006afe It is my understanding that the change exposes bugs in the existing code, and the change-set 41363 [2] and its children fix a lot of those. If you have an easy way to recover, please test, and report the issue to the list with the logs from a good boot (4.12 or commit e6fb1344ed) and the logs from the broken boot. Kind regards, Paul PS: If you have a good boot from a commit in the master branch, please take the time to upload the logs to the board status repository. [1]: https://review.coreboot.org/c/coreboot/+/39486 [2]: https://review.coreboot.org/c/coreboot/+/41363

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2020