Help unsubscribe
-----Original Message-----
From: coreboot-requ...@coreboot.org <coreboot-requ...@coreboot.org>
Sent: 15 May 2020 13:56
To: coreboot@coreboot.org
Subject: coreboot Digest, Vol 183, Issue 25
Send coreboot mailing list submissions to
coreboot@coreboot.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
coreboot-requ...@coreboot.org
You can reach the person managing the list at
coreboot-ow...@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.coll...@ircona.com>
Subject: [coreboot] Help unsubscribe
To: "coreboot@coreboot.org" <coreboot@coreboot.org>
Message-ID: <db6pr04mb29817b043e9cdd70c6a4ad3fa0...@db6pr04mb2981.eur
prd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Help unsubscribe
-----Original Message-----
From: coreboot-requ...@coreboot.org <coreboot-requ...@coreboot.org>
Sent: 14 May 2020 23:55
To: coreboot@coreboot.org
Subject: coreboot Digest, Vol 183, Issue 21
Send coreboot mailing list submissions to
coreboot@coreboot.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
coreboot-requ...@coreboot.org
You can reach the person managing the list at
coreboot-ow...@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 <buu...@gmail.com>
Subject: [coreboot] Re: Resource allocator: multiple boards regression
To: Aaron Durbin <adur...@google.com>
Cc: Mike Banon <mikeb...@gmail.com>, Furquan Shaikh
<furquan.m.sha...@gmail.com>, coreboot <coreboot@coreboot.org>
Message-ID:
<CANTF=bTr=N8i-PZX0coB-uNE4FVXa8OEjk=cft2rdrvhqxd...@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 <adur...@google.com> wrote:
>
>
>
> On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikeb...@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 <buu...@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 <adur...@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 <buu...@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 <adur...@google.com>
>> > >> wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buu...@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.sha...@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 <adur...@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
>> > >> >> > > <adur...@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 <buu...@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
>> > >> >> > >>> <adur...@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 <buu...@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.sha...@gmail.com> wrote:
>> > >> >> > >>> >> >
>> > >> >> > >>> >> > Thanks for the report Keith!
>> > >> >> > >>> >> >
>> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel
>> > >> >> > >>> >> > <pmen...@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@coreboot.org
>> > >> >> > >>> >> > > To unsubscribe send an email to
>> > >> >> > >>> >> > > coreboot-le...@coreboot.org
>> > >> >> > >>> >> _______________________________________________
>> > >> >> > >>> >> coreboot mailing list -- coreboot@coreboot.org
>> > >> >> > >>> >> To unsubscribe send an email to coreboot-le...@coreboot.org
>> > _______________________________________________
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
------------------------------
Date: Thu, 14 May 2020 16:54:29 -0600
From: Aaron Durbin <adur...@google.com>
Subject: [coreboot] Re: Resource allocator: multiple boards regression
To: Keith Hui <buu...@gmail.com>
Cc: Mike Banon <mikeb...@gmail.com>, Furquan Shaikh
<furquan.m.sha...@gmail.com>, coreboot <coreboot@coreboot.org>
Message-ID:
<cae2855tbax_pih9+dgefeu3dwhf6+vqkz6owpbcl2hcnhad...@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 <buu...@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 <adur...@google.com> wrote:
> >
> >
> >
> > On Thu, May 14, 2020 at 2:46 PM Mike Banon <mikeb...@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 <buu...@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 <adur...@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 <buu...@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 <adur...@google.com=
>
> wrote:
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <buu...@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.sha...@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 <
> adur...@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 <
> adur...@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 <
> buu...@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 <
> adur...@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 <
> buu...@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.sha...@gmail.com> wrote:
> >> > >> >> > >>> >> >
> >> > >> >> > >>> >> > Thanks for the report Keith!
> >> > >> >> > >>> >> >
> >> > >> >> > >>> >> > On Wed, May 13, 2020 at 3:42 AM Paul Menzel <
> pmen...@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@coreboot.org
> >> > >> >> > >>> >> > > To unsubscribe send an email to
> coreboot-le...@coreboot.org
> >> > >> >> > >>> >> _______________________________________________
> >> > >> >> > >>> >> coreboot mailing list -- coreboot@coreboot.org
> >> > >> >> > >>> >> To unsubscribe send an email to
> coreboot-le...@coreboot.org
> >> > _______________________________________________
> >> > coreboot mailing list -- coreboot@coreboot.org
> >> > To unsubscribe send an email to coreboot-le...@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"><br></div></div><br><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:buu...@gmail.com";>buu...@gmail.com</a>> wrote=
:<br></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,<br>
<br>
You may want to check the QEMU-q35 target as well:<br>
<br>
Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4<br>
Emulation targets:<br>
"QEMU x86 q35/ich9" using payload TianoCore : FAIL :<br>
<a href=3D"https://lava.9esec.io/r/3427"; rel=3D"noreferrer" target=3D"_blan=
k">https://lava.9esec.io/r/3427</a><br>
"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><br>
"QEMU x86 i440fx/piix4" using payload SeaBIOS : SUCCESS :<br>
<a href=3D"https://lava.9esec.io/r/3425"; rel=3D"noreferrer" target=3D"_blan=
k">https://lava.9esec.io/r/3425</a><br>
"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><br></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"><br>
<br>
Thanks<br>
Keith<br>
<br>
On Thu, May 14, 2020 at 5:47 PM Aaron Durbin <<a href=3D"mailto:adurbin@=
google.com" target=3D"_blank">adur...@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, May 14, 2020 at 2:46 PM Mike Banon <<a href=3D"mailto:mikeb=
d...@gmail.com" target=3D"_blank">mikeb...@gmail.com</a>> wrote:<br>
>><br>
>> Unfortunately it seems a lot of boards are affected by this. A88XM=
-E<br>
>> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed=
at<br>
>> booting - and, when they do, no boot devices are available (virtua=
l<br>
>> floppies too, for some reason) - except coreinfo/tint secondary<br=
>
>> payloads which became prone to freezing. I attach the A88XM-E logs=
<br>
>> I've been able to obtain with USB FT232H:<br>
>><br>
>> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot=
<br>
>> repo's revision where all the stuff works<br>
>> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this comm=
it<br>
>> got the boards broken for the first time<br>
>> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a=
log<br>
>> for coreboot's master top<br>
>><br>
>> For some reason logs for 2) and 3) always stop after "PCI: 00=
:12.2<br>
>> EHCI Debug Port hook triggered".<br>
>><br>
>> I hope these commits could be reverted before we figure out what&#=
39;s<br>
>> going on with them. Good thing we've noticed it fast enough.<b=
r>
>><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> -Aaron<br>
>><br>
>> Best regards,<br>
>> Mike Banon<br>
>><br>
>> On Thu, May 14, 2020 at 8:47 PM Keith Hui <<a href=3D"mailto:bu=
u...@gmail.com" target=3D"_blank">buu...@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi guys,<br>
>> ><br>
>> > 31ab7de51a is CB:41368, cherry picked into my local repo.<br>
>> ><br>
>> > Turns out I have to back out all four of Furquan's patche=
s<br>
>> > (CB:39486~39489) for my board to boot normally again.<br>
>> ><br>
>> > Thoughts?<br>
>> ><br>
>> > I'll now get a log with everything in at SPEW.<br>
>> ><br>
>> ><br>
>> > On Thu, May 14, 2020 at 1:05 PM Aaron Durbin <<a href=3D"m=
ailto:adur...@google.com" target=3D"_blank">adur...@google.com</a>> wrot=
e:<br>
>> > ><br>
>> > > 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.<br>
>> > ><br>
>> > > Allocating resources...<br>
>> > > Reading resources...<br>
>> > > Setting RAM size to 768 MB<br>
>> > > PNP: 03f0.8 missing read_resources<br>
>> > > Done reading resources.<br>
>> > > Resource allocator: DOMAIN: 0000 - Pass 1 (gathering req=
uirements)<br>
>> > > Resource allocator: DOMAIN: 0000 - Pass 2 (allocating re=
sources)<br>
>> > > Resource ranges:<br>
>> > > Base: 1000, Size: d000, Tag: 100<br>
>> > > Base: f000, Size: 1000, Tag: 100<br>
>> > > Resource ranges:<br>
>> > > Base: 0, Size: ff800000, Tag: 200<br>
>> > > Base: 100000000, Size: f00000000, Tag: 100200<br>
>> > > Resource ranges:<br>
>> > > Base: 10000000, Size: 8000000, Tag: 1200<br>
>> > > Resource ranges:<br>
>> > > Base: 18000000, Size: 1100000, Tag: 200<br>
>> > ><br>
>> > > This is the memory address space:<br>
>> > > Base: 0, Size: ff800000, Tag: 200<br>
>> > > Base: 100000000, Size: f00000000, Tag: 100200<br>
>> > ><br>
>> > > Those are valid ranges to choose dynamic resources from.=
<br>
>> > ><br>
>> > > PCI: 00:00.0 10 <- [0x0000000000 - 0x000fffffff] size=
0x10000000 gran 0x1c prefmem<br>
>> > ><br>
>> > > I see 'Setting RAM size to 768 MB' which means I=
would expect to see a hole in the ranges representing 768MiB.<br>
>> > ><br>
>> > > 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.<br>
>> > ><br>
>> > > Also, what mainboard Kconfig are you selecting for p3bf?=
src/mainboard/asus/p2b ?<br>
>> > ><br>
>> > ><br>
>> > ><br>
>> > > On Thu, May 14, 2020 at 10:42 AM Keith Hui <<a href=
=3D"mailto:buu...@gmail.com"; target=3D"_blank">buu...@gmail.com</a>> wro=
te:<br>
>> > >><br>
>> > >> (Temporarily leaving the list out)<br>
>> > >><br>
>> > >> Hi Aaron,<br>
>> > >><br>
>> > >> Here is a log with everything including CB:41368 inc=
luded. I'll get<br>
>> > >> this log out to you first, while I try a build with =
all problem<br>
>> > >> commits left out.<br>
>> > >><br>
>> > >> Thanks<br>
>> > >> Keith<br>
>> > >><br>
>> > >> On Thu, May 14, 2020 at 12:53 AM Aaron Durbin <<a=
href=3D"mailto:adur...@google.com"; target=3D"_blank">adur...@google.com</a=
>> wrote:<br>
>> > >> ><br>
>> > >> ><br>
>> > >> ><br>
>> > >> > On Wed, May 13, 2020 at 10:51 PM Keith Hui <=
<a href=3D"mailto:buu...@gmail.com"; target=3D"_blank">buu...@gmail.com</a>&=
gt; wrote:<br>
>> > >> >><br>
>> > >> >> Hi guys,<br>
>> > >> >><br>
>> > >> >> I tested these fixes on my board, and I hav=
e to say there's still<br>
>> > >> >> something wrong. They did address the hang =
or reset in SeaBIOS I first<br>
>> > >> >> described, but now either my ATA hard drive=
failed to boot (it tried<br>
>> > >> >> to hand off to GRUB on my drive, but didn&#=
39;t get there), or it can't<br>
>> > >> >> find the option ROM of my video card, meani=
ng no display.<br>
>> > >> >><br>
>> > >> >> Now I want to try the other way, testing a =
build with all changes<br>
>> > >> >> related to the problem backed out instead. =
So besides the one I first<br>
>> > >> >> identified, what other related patches shou=
ld I try backing out?<br>
>> > >> ><br>
>> > >> ><br>
>> > >> > 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.<br>
>> > >> ><br>
>> > >> > Thanks.<br>
>> > >> ><br>
>> > >> > -Aaron<br>
>> > >> ><br>
>> > >> >><br>
>> > >> >> On Wed, May 13, 2020 at 11:54 PM Furquan Sh=
aikh<br>
>> > >> >> <<a href=3D"mailto:furquan.m.shaikh@gmai=
l.com" target=3D"_blank">furquan.m.sha...@gmail.com</a>> wrote:<br>
>> > >> >> ><br>
>> > >> >> > 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><br>
>> > >> >> ><br>
>> > >> >> > On Wed, May 13, 2020 at 11:29 AM Aaron=
Durbin <<a href=3D"mailto:adur...@google.com"; target=3D"_blank">adurbin=
@google.com</a>> wrote:<br>
>> > >> >> > ><br>
>> > >> >> > > 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.<br>
>> > >> >> > ><br>
>> > >> >> > > On Wed, May 13, 2020 at 11:13 AM =
Aaron Durbin <<a href=3D"mailto:adur...@google.com"; target=3D"_blank">ad=
ur...@google.com</a>> wrote:<br>
>> > >> >> > >><br>
>> > >> >> > >> 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.<br>
>> > >> >> > >><br>
>> > >> >> > >> On Wed, May 13, 2020 at 10:59=
AM Keith Hui <<a href=3D"mailto:buu...@gmail.com"; target=3D"_blank">buu=
r...@gmail.com</a>> wrote:<br>
>> > >> >> > >>><br>
>> > >> >> > >>> Hi Aaron,<br>
>> > >> >> > >>><br>
>> > >> >> > >>> It didn't help. There=
still a way out of whack entry in the coreboot<br>
>> > >> >> > >>> table and e820 entry endi=
ng at 000003ffffffffff, which I think have<br>
>> > >> >> > >>> more to do than the 41363=
's scope.<br>
>> > >> >> > >>><br>
>> > >> >> > >>> Keith<br>
>> > >> >> > >>><br>
>> > >> >> > >>> On Wed, May 13, 2020 at 1=
2:24 PM Aaron Durbin <<a href=3D"mailto:adur...@google.com"; target=3D"_b=
lank">adur...@google.com</a>> wrote:<br>
>> > >> >> > >>> ><br>
>> > >> >> > >>> > 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.<br>
>> > >> >> > >>> ><br>
>> > >> >> > >>> > On Wed, May 13, 2020=
at 8:43 AM Keith Hui <<a href=3D"mailto:buu...@gmail.com"; target=3D"_bl=
ank">buu...@gmail.com</a>> wrote:<br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> Thanks Furquan.<=
br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> Here are 3 logs.=
Log 1 is at the commit just before the problem. Log 2<br>
>> > >> >> > >>> >> is at the proble=
m commit. Log 3 is at the current master, if that's<br>
>> > >> >> > >>> >> what you meant b=
y ToT.<br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> I'm using Se=
aBIOS 1.13.0, compiled once using the attached .config<br>
>> > >> >> > >>> >> before taking th=
ese logs. All 3 runs are taken using the same SeaBIOS<br>
>> > >> >> > >>> >> binary.<br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> Then I recompile=
d SeaBIOS with CONFIG_RELOCATE_INIT off, replaced the<br>
>> > >> >> > >>> >> payload used in =
run 3, and took an extra run. In this case the board<br>
>> > >> >> > >>> >> reset on its own=
at "Scanning option roms", looping infinitely.<br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> Hope this helps<=
br>
>> > >> >> > >>> >> Keith<br>
>> > >> >> > >>> >><br>
>> > >> >> > >>> >> On Wed, May 13, =
2020 at 7:38 AM Furquan Shaikh<br>
>> > >> >> > >>> >> <<a href=3D"m=
ailto:furquan.m.sha...@gmail.com" target=3D"_blank">furquan.m.shaikh@gmail.=
com</a>> wrote:<br>
>> > >> >> > >>> >> ><br>
>> > >> >> > >>> >> > Thanks for =
the report Keith!<br>
>> > >> >> > >>> >> ><br>
>> > >> >> > >>> >> > On Wed, May=
13, 2020 at 3:42 AM Paul Menzel <<a href=3D"mailto:pmen...@molgen.mpg.d=
e" target=3D"_blank">pmen...@molgen.mpg.de</a>> wrote:<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > Dear K=
eith,<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > Am 13.=
05.20 um 05:21 schrieb Keith Hui:<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > > I=
am still refining the P2B family of boards, now including the<br>
>> > >> >> > >>> >> > > > i=
nfamous P3B-F with an unusual appetite for hacks to make work.<br>
>> > >> >> > >>> >> > > ><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<br>
>> > >> >> > >>> >> > > > g=
it bisect, I decided to try it out.<br>
>> > >> >> > >>> >> > > ><b=
r>
>> > >> >> > >>> >> > > > I=
t was commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7 [1] that broke<br>
>> > >> >> > >>> >> > > > m=
y SeaBIOS. It doesn't affect my newer toy the P8Z77-M as much as<br>
>> > >> >> > >>> >> > > > P=
3B-F, but I still want to blame that, and probably the very next<br>
>> > >> >> > >>> >> > > > c=
ommit as well, as they both deal with some very modern aspects of PCI<br>
>> > >> >> > >>> >> > > > t=
hat well predates the 440BX.<br>
>> > >> >> > >>> >> > > ><b=
r>
>> > >> >> > >>> >> > > > I=
s there anything we can do to fix 3b02006afe?<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > I comm=
ented in the change-set [1] to make the author and reviewers aware<br>
>> > >> >> > >>> >> > > of thi=
s issue and referenced your list message, and ask to comment here.<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > Could =
you please provide the debug log of coreboot and SeaBIOS?<br>
>> > >> >> > >>> >> ><br>
>> > >> >> > >>> >> > As Paul men=
tioned, can you please provide the debug logs for coreboot<br>
>> > >> >> > >>> >> > and SeaBIOS=
both with ToT coreboot and with HEAD set before the change<br>
>> > >> >> > >>> >> > 3b02006afe =
where it does not hang? Thanks!<br>
>> > >> >> > >>> >> ><br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > > M=
eanwhile I ported the P3B-F board enable to flashrom [2], which got a<br>
>> > >> >> > >>> >> > > > h=
eavy workout during this bisect, through vendor firmware and both<br>
>> > >> >> > >>> >> > > > g=
ood and bad builds of coreboot. In all cases I can flash internal, no<br>
>> > >> >> > >>> >> > > > l=
onger having to haul out my P2B-LS just to use it as a flasher.<br>
>> > >> >> > >>> >> > > ><b=
r>
>> > >> >> > >>> >> > > > E=
njoy this long overdue board enable. If it gets submitted, I'll<br>
>> > >> >> > >>> >> > > > r=
etract the ramstage hack[3] doing the same as redundant.<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > 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<br>
>> > >> >> > >>> >> > > device=
and improves the firmware showing that Free Software is the more<br>
>> > >> >> > >>> >> > > sustai=
nable way.<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > Kind r=
egards,<br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > Paul<b=
r>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > ><br>
>> > >> >> > >>> >> > > > [=
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>
>> > >> >> > >>> >> > > ______=
_________________________________________<br>
>> > >> >> > >>> >> > > corebo=
ot mailing list -- <a href=3D"mailto:coreboot@coreboot.org"; target=3D"_blan=
k">coreboot@coreboot.org</a><br>
>> > >> >> > >>> >> > > To uns=
ubscribe send an email to <a href=3D"mailto:coreboot-le...@coreboot.org"; ta=
rget=3D"_blank">coreboot-le...@coreboot.org</a><br>
>> > >> >> > >>> >> ________________=
_______________________________<br>
>> > >> >> > >>> >> coreboot mailing=
list -- <a href=3D"mailto:coreboot@coreboot.org"; target=3D"_blank">coreboo=
t...@coreboot.org</a><br>
>> > >> >> > >>> >> To unsubscribe s=
end an email to <a href=3D"mailto:coreboot-le...@coreboot.org"; target=3D"_b=
lank">coreboot-le...@coreboot.org</a><br>
>> > _______________________________________________<br>
>> > coreboot mailing list -- <a href=3D"mailto:coreboot@coreboot.=
org" target=3D"_blank">coreboot@coreboot.org</a><br>
>> > To unsubscribe send an email to <a href=3D"mailto:coreboot-le=
a...@coreboot.org" target=3D"_blank">coreboot-le...@coreboot.org</a><br>
</blockquote></div></div>
--00000000000010123505a5a3957a--
------------------------------
Subject: Digest Footer
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
------------------------------
End of coreboot Digest, Vol 183, Issue 21
*****************************************
------------------------------
Subject: Digest Footer
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
------------------------------
End of coreboot Digest, Vol 183, Issue 25
*****************************************
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
