Re: [coreboot] [RFH] Native AMD fam10-15 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/2018 01:36 PM, qtux wrote: > On 15/06/18 13:51, Kyösti Mälkki wrote: >> On Fri, Jun 15, 2018 at 2:14 PM, qtux wrote: >> >>> > Coreboot did work well, but froze sometimes when booting during the > assigning resources step (more or less exactly after assigning the PCI > 14.3 or PNP 002e.2 device, which happen to be close to each other inside > the devicetree). I had to remove the power cord in order to be able to > boot again (or to get the next random freeze...). Rarely, after such an > recovery, I have got flooded by IOMMU warnings in Linux which would only > disappear after another reboot. Ah, that resume reboot-loop issue. The bit that tells to do S3 resume is a sticky register backed up by Vstb rail. With [2] you should not need to do full power-cycling at least. We should extend this work to other platforms. >>> >>> I am not sure whether the term resume reboot-loop applies for my issue >>> (side note: I used a serial connection to monitor the boot process): >>> >>> Rebooting (via holding the power button for some seconds) after >>> encountering a freeze (aka stopping at the assign resource step) >>> resulted into having no output from serial at all. I could repeat this >>> with no effect at all, the computer seemed to be dead. Only removing the >>> power cord could solve the issue. >>> >>> This issue could occur when rebooting but even when cold booting. >>> >> >> One of these boards had LPC related lockups. I think the solution was to >> disable serial console or to set console to low loglevel. >> > > If that is the case I would suggest to alter the default board > configuration to reflect this. Nevertheless, it seems strange to me that > such a lockup disappeared after changing SPI chips. > >> >> >>> Answers are inside the text. >>> I forgot to mention that I am currently on commit 793ae846e8. >>> >> >> Let's take the parent of that, commit 4a027e6e -- the one you refer to only >> appears on gerrit review branch. >> >> Kyösti >> >> >> > > That is fine, sorry for the misleading commit hash. > > Cheers, > Matthias > I've actually done a lot of investigation of this issue over time, including work with a protocol analyzer. What happens is that at some point (not sure where or why) the SPI flash reads start occurring at addresses that are completely invalid -- basically, the board starts reading compressed ramstage data during early romstage execution. This could be down to an SPI misread somewhere, but more importantly it appears that: 1.) The SPI controller in the southbridge receives at least some leakage power from +5VSB, and retains state as a result while the PSU is plugged in. 2.) The board reset lines don't fully reset the SPI controller in the southbridge 3.) There is an as-of-yet undetermined command sequence that will hard lock the SPI controller. Much of this had been mitigated by making sure the ROM bridge in the southbridge never switched to LPC Flash mode, and I'm surprised to hear these issues are still happening. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbJCi+AAoJEK+E3vEXDOFbVPYIAJWT6y/0LuTAK1V9rNz9uav/ 6SKomv6W4GcsV4gRg9j/ROA2hK64ljsfFVZzcEwMVLi6mE6iYG5vnLHM/MGTUOJT emQ2nqXNkzrovhgxFL1Xw6cpnhqIvCBqRz0ILMeRiXBniHXYW4AtNWsdh9rXIAOB uhQSg3HMFqF9mXdBV3PUB0mn1FfEUcsHYcrYwu2A7JJtESYrWHV/IXaFfsC431J1 u6tcapbqNv2sfeDRcIkafxoE1IuVO17KT35UNQLauShsHr/R+519x17k3Bx2RoRN 9YsdjwCfmWtIaokAx3PGRbStlqXa790yONDVIU4+8SpDxzqeB6XgKCXfGyyIo7A= =tO92 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On 15/06/18 13:51, Kyösti Mälkki wrote: > On Fri, Jun 15, 2018 at 2:14 PM, qtux wrote: > >> Coreboot did work well, but froze sometimes when booting during the assigning resources step (more or less exactly after assigning the PCI 14.3 or PNP 002e.2 device, which happen to be close to each other inside the devicetree). I had to remove the power cord in order to be able to boot again (or to get the next random freeze...). Rarely, after such an recovery, I have got flooded by IOMMU warnings in Linux which would only disappear after another reboot. >>> >>> Ah, that resume reboot-loop issue. The bit that tells to do S3 resume >>> is a sticky register backed up by Vstb rail. With [2] you should not >>> need to do full power-cycling at least. We should extend this work to >>> other platforms. >>> >> >> I am not sure whether the term resume reboot-loop applies for my issue >> (side note: I used a serial connection to monitor the boot process): >> >> Rebooting (via holding the power button for some seconds) after >> encountering a freeze (aka stopping at the assign resource step) >> resulted into having no output from serial at all. I could repeat this >> with no effect at all, the computer seemed to be dead. Only removing the >> power cord could solve the issue. >> >> This issue could occur when rebooting but even when cold booting. >> > > One of these boards had LPC related lockups. I think the solution was to > disable serial console or to set console to low loglevel. > If that is the case I would suggest to alter the default board configuration to reflect this. Nevertheless, it seems strange to me that such a lockup disappeared after changing SPI chips. > > >> Answers are inside the text. >> I forgot to mention that I am currently on commit 793ae846e8. >> > > Let's take the parent of that, commit 4a027e6e -- the one you refer to only > appears on gerrit review branch. > > Kyösti > > > That is fine, sorry for the misleading commit hash. Cheers, Matthias -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear All,
After following the recommendations from Rudolf and other people on this mail
list I was able to make the following to make my LPC SIO to work (with issues).
1.- Enable SERIRQ in CONTINUOUS_MODE
2.- Add SUPERIO_WINBOND_W83627DHG driver to the Konfig file.
3.- Add the SIO parametrization in devicetree with 0x3f8,4 and 0x2f8,3 for
UARTS.
4.- Add the PNP-ACPI information for SIO.
5.- Change SOC's 8259 trigger to EDGE.
6.- Disable internal (SOC) COM1 with the following code in romstage:
void late_mainboard_romstage_entry()
{
/* Disable the internal COM1 */
pci_write_config32(PCI_DEV(0, LPC_DEV, 0), UART_CONT, 0);
u32 *irqen = (u32 *)(ILB_BASE_ADDRESS + 0x88);
write32(irqen, 0); /* Unbind IRQ4 */
}
7.- Release IRQ4 from the PIRQ_PIC_ROUTES in irqroute.h and set IRQ6 instead.
After all this:
COM2 (0x2f8,3) works fine
But:
I still have an issue:
COM1 (0x3f8,4) can transmit data correctly but at receiving the port hangs and
not showing received string.
When I make DMESG in terminal i get:
"do_IRQ: 2.39 No irq handler for vector"
"serial8250: too much work for irq4"
What could be wrong?
What could be missing?
Let me know if you require more info,
Any advise on the issue will be highly appreciated,
Thank you,
J. Trujillo
‐‐‐ Original Message ‐‐‐
On June 6, 2018 11:46 PM, Rudolf Marek wrote:
> Hi,
>
> In general I would check ELCR (I/O port register 0x4d0) to check if it is
> correctly programmed to EDGE/LEVEL (it should be edge)
>
> Also, how the Linux is supposed to detect the I/O port irq? I think you need
> some PNP device in ACPI to let linux infer the IRQ.
>
> I would also try to disable the IRQ from SoC, you just need to check how they
> are enabled (sorry not an expert here)
>
> and also I would use the legacy 0x3f8 instead.
>
> Thanks
>
> Rudolf
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] New Defects reported by Coverity Scan for coreboot
Hi,
Please find the latest report on new defect(s) introduced to coreboot found
with Coverity Scan.
1 new defect(s) introduced to coreboot found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1393458:(DEADCODE)
/src/northbridge/intel/x4x/raminit_ddr23.c: 1685 in set_dradrb()
/src/northbridge/intel/x4x/raminit_ddr23.c: 1720 in set_dradrb()
/src/northbridge/intel/x4x/raminit_ddr23.c: 1743 in set_dradrb()
*** CID 1393458:(DEADCODE)
/src/northbridge/intel/x4x/raminit_ddr23.c: 1685 in set_dradrb()
1679
1680if (s->stacked_mode) {
1681dual_channel_size = 0;
1682} else if (size_me == 0) {
1683dual_channel_size = MIN(size_ch0, size_ch1) * 2;
1684} else {
>>> CID 1393458:(DEADCODE)
>>> Execution cannot reach this statement: "if (size_ch0 == 0U) {
siz...".
1685if (size_ch0 == 0) {
1686/* ME needs ram on CH0 */
1687size_me = 0;
1688/* TOTEST: bailout? */
1689} else {
1690/* Set ME UMA size in MiB */
/src/northbridge/intel/x4x/raminit_ddr23.c: 1720 in set_dradrb()
1714if (!(s->stacked_mode && size_ch0 != 0 && size_ch1 !=
0)) {
1715map |= 0x04;
1716if (size_ch0 <= size_ch1)
1717map |= 0x01;
1718}
1719} else {
>>> CID 1393458:(DEADCODE)
>>> Execution cannot reach this statement: "if (s->stacked_mode == 0 &&...".
1720if (s->stacked_mode == 0 && size_ch0 - size_me <
size_ch1)
1721map |= 0x04;
1722}
1723
1724MCHBAR8(0x110) = map;
1725MCHBAR16(0x10e) = 0;
/src/northbridge/intel/x4x/raminit_ddr23.c: 1743 in set_dradrb()
1737if (size_ch0 > size_ch1)
1738single_channel_offset = dual_channel_size / 2
1739+ single_channel_size;
1740else
1741single_channel_offset = dual_channel_size / 2;
1742} else {
>>> CID 1393458:(DEADCODE)
>>> Execution cannot reach this statement: "if (size_ch0 > size_ch1 && ...".
1743if ((size_ch0 > size_ch1) && ((map & 0x7) == 4))
1744single_channel_offset = dual_channel_size / 2
1745+ single_channel_size;
1746else
1747single_channel_offset = dual_channel_size / 2
1748+ size_me;
To view the defects in Coverity Scan visit,
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5ZWQAhKLOAsZdzAaxClABVCPKncVmMBWRp7PRtJ8U4UsZvhqlZH5D0rL5ZrSm-2FDI3jRyovYoUJWejXIVkPwEXu-2FkctkwoohoASCOBhHjBIP2ZZVMo6AcGNvqUK2EAPUYfoaylt-2FOj6pDdbZ1Ym-2BaYJpmQKm3JuWa728adeW7h611nnn4d4ZyG-2Foxxi8WSrHFpk-3D
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On Fri, Jun 15, 2018 at 2:14 PM, qtux wrote: > > >> Coreboot did work well, but froze sometimes when booting during the > >> assigning resources step (more or less exactly after assigning the PCI > >> 14.3 or PNP 002e.2 device, which happen to be close to each other inside > >> the devicetree). I had to remove the power cord in order to be able to > >> boot again (or to get the next random freeze...). Rarely, after such an > >> recovery, I have got flooded by IOMMU warnings in Linux which would only > >> disappear after another reboot. > > > > Ah, that resume reboot-loop issue. The bit that tells to do S3 resume > > is a sticky register backed up by Vstb rail. With [2] you should not > > need to do full power-cycling at least. We should extend this work to > > other platforms. > > > > I am not sure whether the term resume reboot-loop applies for my issue > (side note: I used a serial connection to monitor the boot process): > > Rebooting (via holding the power button for some seconds) after > encountering a freeze (aka stopping at the assign resource step) > resulted into having no output from serial at all. I could repeat this > with no effect at all, the computer seemed to be dead. Only removing the > power cord could solve the issue. > > This issue could occur when rebooting but even when cold booting. > One of these boards had LPC related lockups. I think the solution was to disable serial console or to set console to low loglevel. > Answers are inside the text. > I forgot to mention that I am currently on commit 793ae846e8. > Let's take the parent of that, commit 4a027e6e -- the one you refer to only appears on gerrit review branch. Kyösti -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On 15/06/18 02:42, Kyösti Mälkki wrote: > On Thu, Jun 14, 2018 at 4:38 AM, qtux wrote: >> On 13/06/18 22:12, Kyösti Mälkki wrote: >> Hi, >> >> S3 is __not__ working on my KCMA-D8. The last time I tried, I had to >> remove the power cord for a couple of seconds to be able to boot again. >> >> Interestingly, this issue looks similar to another one I had with a >> flash chip which seems not to be supported by coreboot. Here the >> relevant part of the logs regarding the bad chip: >> Manufacturer: ef >> SF: Unsupported Winbond ID 4014 >> SF: Unsupported manufacturer! >> > > Thanks, [1] should take care of this. > Thank you! I will test the Winbond chip when I find some time to do so. >> Coreboot did work well, but froze sometimes when booting during the >> assigning resources step (more or less exactly after assigning the PCI >> 14.3 or PNP 002e.2 device, which happen to be close to each other inside >> the devicetree). I had to remove the power cord in order to be able to >> boot again (or to get the next random freeze...). Rarely, after such an >> recovery, I have got flooded by IOMMU warnings in Linux which would only >> disappear after another reboot. > > Ah, that resume reboot-loop issue. The bit that tells to do S3 resume > is a sticky register backed up by Vstb rail. With [2] you should not > need to do full power-cycling at least. We should extend this work to > other platforms. > I am not sure whether the term resume reboot-loop applies for my issue (side note: I used a serial connection to monitor the boot process): Rebooting (via holding the power button for some seconds) after encountering a freeze (aka stopping at the assign resource step) resulted into having no output from serial at all. I could repeat this with no effect at all, the computer seemed to be dead. Only removing the power cord could solve the issue. This issue could occur when rebooting but even when cold booting. >> Replacing the chip seems to have solved this random boot freeze problem. >> But maybe the S3 issue and the issue I had with the wrong chip are >> related as they both lock down the machine until I remove the power cord. > > Yes, it's connected. Having a non-supported SPI part ID there would > prevent ACPI S3 resume, and likely enter the loop.> Just to be sure: The S3 resume does not work with the __supported__ SPI chip. I did not test S3 with the unsupported one. > If someone takes the task of testing and/or bisecting please note: > > Regression present between: 714709f .. a26377b > > Regression present between: 9e94dbf .. c2a921b (for kcma-d8) 8a8386e > (for kgpe-d16) > > Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is > within the latter period, I do not quite see how S3 support could have > worked with that commit on kgpe-d16. Or maybe this feature was never > retested once it was rebased and upstreamed. Nor can I see how it > could have worked for any commit in 4.6, so I must be missing > something here. So I will need some logs. > > > [1] https://review.coreboot.org/#/c/coreboot/+/27107 > [2] https://review.coreboot.org/#/c/coreboot/+/27108 > > Kyösti > Answers are inside the text. I forgot to mention that I am currently on commit 793ae846e8. Cheers, Matthias -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com wrote: > On 06/14/2018 08:42 PM, Kyösti Mälkki wrote: > > On Thu, Jun 14, 2018 at 4:38 AM, qtux wrote: > > Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is > > within the latter period, I do not quite see how S3 support could have > > worked with that commit on kgpe-d16. Or maybe this feature was never > > retested once it was rebased and upstreamed. Nor can I see how it > > could have worked for any commit in 4.6 > > I just tested S3 again and it worked fine on my v4.6 D16. > Please state the commit hash of the source tree you built and booted from, we don't literally have such tag as "v4.6". Repeat tests with current master. Thanks Kyösti -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On 06/14/2018 08:42 PM, Kyösti Mälkki wrote: > On Thu, Jun 14, 2018 at 4:38 AM, qtux wrote: > Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is > within the latter period, I do not quite see how S3 support could have > worked with that commit on kgpe-d16. Or maybe this feature was never > retested once it was rebased and upstreamed. Nor can I see how it > could have worked for any commit in 4.6 I just tested S3 again and it worked fine on my v4.6 D16. My Win10 guest with IOMMU-GFX also resumes properly as long as it is suspended first before the host which places the assigned devices in S3. It takes a LONG time (around a minute) to resume so it isn't quick but it does work. > so I must be missing something here. So I will need some logs. Ah tell me what you want and I will provide it ASAP :D -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFH] Native AMD fam10-15 support
On 06/14/2018 02:45 AM, Kyösti Mälkki wrote: > On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com wrote: >> On 06/13/2018 04:12 PM, Kyösti Mälkki wrote: >>> Hi >>> >>> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards. >> What exactly do you mean by wiped out? >> >>> >>> Couple questions for board owners: >>> >>> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3 >>> support? I remember rumours they originally worked at some point, but >>> regressed during the rebase / upstream process. Anyone willing to >>> bisect/fix it if necessary? >>> >> >> I have a D16 with v4.6 that I regularly use suspend with and it works >> absolutely fine - I can also suspend a host featuring a guest with IOMMU >> graphics and then resume that host later on and continue playing video >> games on the guest. > > So you are committed to bisect this and make it work on current > master, thank you. Yes I am, like I said this worked quite recently so I doubt it will be that difficult to fix although I will have to have someone else publish whatever I find. I own both of these and value them quite a bit so I will be putting efforts in to this - In reference to my previous offer to support the H8SCM I abandoned that effort as it went from $30 used to over $200 and I didn't see the point after that (as one should just get a KCMA-D8 or KGPE-D16 at that point) The D8 and D16 are the last and best owner controlled x86 boards the only coreboot boards left with 100% open source hardware initiation. Like I have said before at this rate there will be no boards in master besides *brand new* purism laptops and un-obtainable development boards where half the features don't work anyway - I fail to see how that makes for a healthy project if no one (again remember I have said you do quite a bit already) is willing to support the two boards that I would argue are the best examples of coreboot and modern computing freedom efforts. >> >> I again state my for-some-reason controversial opinion that at this rate >> there will soon be no non-development boards in coreboot due to the >> choices of the current leadership in determining standards. > > I hear you and weigh your opinion according to the number of commits I > can recognize you have authored on the repo. I didn't mean it like that man - you have done quite a bit for computing freedom and I have recognized that on various occasions. As I am unwilling to provide my "real" name I am not allowed to contribute code so I help in other ways - I have spent countless hours assisting many many people with recommending boards to purchase and then getting coreboot running on them. Contributing code isn't the only measure of worth, every project needs people to provide tech support and documentation and I do just that. I do feel as though lately there has been a turn for elitism where anyone who doesn't contribute code is discounted and made to feel unwelcome as if our opinion doesn't really matter and I do not like this...but again I say you are one of my favorites. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] wiki backup
On 06/14/2018 08:41 PM, Martin Roth wrote: > On Thu, Jun 14, 2018 at 12:35 PM Leah Rowe wrote: >> On 14/06/18 19:01, Martin Roth wrote: > >>> * The wiki requires a separate login from everything else, which >>> has to be created manually. >> Not only that, but it wasn't clear how to get an account in the first >> place> > I guess I didn't realize that it was a problem. If you clicked 'log > in' in the top of the wiki, it told you who to email along with their > addresses. Yeah it was quite clear to me how to get an account when I first wanted to contribute and it only took a few days to get approved despite the fact that I am certainly not a member of the coreboot elite xD > "If you don't have an account and wish to contribute contact Stefan > Reinauer or Patrick Georgi and tell them what exactly you want to > contribute." > https://web.archive.org/web/2015103952/http://www.coreboot.org:80/index.php?title=Special:UserLogin=Welcome+to+coreboot I must say that Mr. georgi was quite welcoming in granting me an account as a new user - and I have repaid that with a many helpful edits and created pages. >> By the way, what do you think of the idea I floated in a previous >> message? My idea is to have some kind of web interface where a >> non-technical user who doesn't know how to use git can browse the >> documentation on the website and click "edit", which will take them to >> the appropriate markdown file in the repository. When they're done, >> they give their edit a title and description, which becomes the commit >> message, and their contribution gets sent to code review (Gerrit). >> >> How feasible do you think this would be? >> It would give some of the ease of use of MediaWiki as before, while >> still having all of the advantages that you listed. > > I have no issue with that if someone wanted to work on it. It might > still cause some difficulties because those people probably wouldn't > be able to respond to requests for updates in gerrit An email could be automatically sent to them for that, and then replying to it could automatically create a reply on gerrit. > and they > wouldn't necessarily follow the rest of the rules we have for > submitting to coreboot, but maybe those issues could be worked out. > Maybe a documentation administrator could shepherd the patches the > rest of the way through the process.> > As far as feasibility, I'm sure it could be done, it would just take > someone committed to making it happen. This would be quite nice in terms of usability and I very much hope someone makes it. Also can someone answer: I presume that editing the wiki it requires my "real" name as it is on git? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
