coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

[RFC] Building the documentation with Sphinx
by Jonathan Neuschäfer 10 May '18

10 May '18

Hello coreboot community, recently, I tried to use Hugo view some documentation in HTML form, but I couldn't get it to work properly (some pages 404'd when they shouldn't). So I decided to look into using Sphinx[1] again. I configured[2] Sphinx and the recommonmark Markdown parser for our Documentation directory. The result can be viewed here: https://neuschaefer.github.io/coreboot/ Advantages of this approach: - The "readthedocs" theme, which I used has a useful navigation sidebar and allows full navigation without JavaScript (the search box does need JavaScript, because the search is performed on the client side.) - The top-level table of contents (i.e. the navbar) is generated from a markdown file[3] rather than a special configuration file[4]. - The necessary packages (sphinx-doc, python-recommonmark, python-sphinx-rtd-theme) are available in Debian; but so is Hugo. Disadvantages: - recommonmark does not support tables[5]. This is a limitation of the CommonMark[6] dialect of Markdown. We'd have to use HTML tables (<table>...</table>) instead. - If we decide to switch https://coreboot.org/Documentation to Sphinx, that would mean some work for the admins, like any other change in infrastructure. Possible migration path: - Merge Sphinx support - Look how well it works, and decide whether it's worth keeping, or drop it - Switch https://coreboot.org/Documentation (or https://doc.coreboot.org/?) to Sphinx - Remove hugo support Overall, I like this setup, and I'd like https://coreboot.org/Documentation to switch to it, but it has a few limitations. I'd like to hear your opinions! Thanks, Jonathan Neuschäfer [1]: http://www.sphinx-doc.org/en/stable/ [2]: https://review.coreboot.org/#/c/coreboot/+/25787/ [3]: https://review.coreboot.org/#/c/coreboot/+/25787/1/Documentation/index.md [4]: https://review.coreboot.org/cgit/coreboot.git/tree/util/hugo/config.toml#n30 [5]: https://github.com/rtfd/recommonmark/issues/3 [6]: http://commonmark.org/

2 1

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 10 May '18

10 May '18

> In general, I like Nico's idea of setting up rules for blobs, but my > worry is that no matter how great and logical the rules are, the > blob-makers might simply ignore them.. you can ask for signed blobs, > but what if they refuse to sign it? Or even better, you can ask for > redistributable blobs, but what if they refuse to make them > redistributable? Will you simply stop supporting any boards that > depend on those blobs? You'd have to eventually compromise (for the > sake of the users/project) and break your own rules that you worked so > hard to perfect... Since they control the blobs, they have the power, > unless you think "integrate in coreboot" is a hard requirement for > them, and in that case, if you set up those rules, they would be > forced to follow them, that can actually help get things done the > right way instead of just asking nicely and never getting a positive > response. I don't really know... it might work for Intel/CrOS for > example, but maybe not for other vendors who wouldn't need to be > integrated in coreboot... Well, you can't argue much about what will happen if you set up some rules if you never tried. Sure, the rules could fail us. But is it not worth trying? I'm seeing a lot of bad things on Gerrit where the only argument seems to be that ppl were allowed to do the same with other platforms (just because a single reviewer was lax?). Having some written rules that you can refer to could help a lot, IMHO. I know I might be generalizing too much about what Intel does. But, AFAICS, for all non-Intel platforms, ppl seem to have done reasonably well enough so that the platforms can already comply with my draft rules. Which also shows that it can't be too hard. > > Anyway, to resolve the immediate issue with the header, how about > adding a 'variants' system, like we already have with mainboards? > Something like : > src/vendorcode/intel/fsp/fsp2_0/variants/google/*.h > src/vendorcode/intel/fsp/fsp2_0/variants/github/*.h > and in the Kconfig, we could just set FSP_VARIANT_DIR="github" > That would be (I assume) much less messy than having #ifdefs to > define-or-not specific fields in the UPD structures. > The only issue would be with regards to fields that coreboot uses that > aren't available in a variant, like for example, the > PcieRpClkSrcNumber field that doesn't exist in the github header but > is used in coreboot, there are a couple of solutions to that : > 1 - add #define HAVE_PCIE_RP_CLK_SRC_NUMBER (for example) in the > headers and have #ifdefs everywhere in coreboot code. This is not a > great idea > 2 - have something like "#define PcieRpClkSrcNumber UnusedUpdSpace26", > but that would add so much problems that it's a very stupid idea... > why am I ever writing this? > 3 - manually add the missing fields somewhere in the Upd and only have > the changes between two variants where the field offsets change in the > structure. > 4 - anyone else with better ideas? As I can't propose to you to make the homework for multi-billion corporations, plus the problem wouldn't exist if I hadn't been run over on Gerrit: 4. Ditch the code that references the missing UPDs. Nico

1 0

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 09 May '18

09 May '18

On 08.05.2018 20:35, Julius Werner wrote: >>>> Providers of blobs should sign them and take responsibility >>>> that the signed blobs were unaltered after compilation (e.g. >>>> do not contain malware). It is *recommended* that the public >>>> key needed to verify the signature is obtainable through a >>>> specific channel (e.g. single responsible contact person) >>>> _independently_ from the blob's distribution path. > > I'm not quite sure what the point of this would be for blobs that are > already checked into 3rdparty/blobs, and I could imagine that it would be a > surprisingly big obstacle for a lot of vendors. Please don't only think of > Intel when trying to make these rules... not every vendor has the resources > to set up their own blob distribution site with regular versioned releases > on GitHub. On Arm systems the blob may often be designed specifically for > coreboot, and the vendor loses interest as soon as the project they were > paid to support (e.g. a Chromebook) is finished. I think this should still > be fine as long as they uploaded it with a proper redistribution license to > blobs.git, and implemented the coreboot interface with enough documentation > to make it usable afterwards. For vendors like Intel that insist on hosting > their blobs externally, I think it's fair to impose more rules to avoid the > problems you've described, but we should still leave open an easier option > for vendors that are willing to redistribute their blobs through > coreboot.org (which I think is the much nicer option for us, so we should > incentivize it). Yes, I agree and already did so when writing the above. That's why I made it a recommendation and not a requirement. I also intentionally didn't write "vendor". Just whoever provides the blob should sign it. > >>>> For each platform that relies on a blob, the coreboot tree >>>> *should* point (e.g. git submodule) to a commit containing >>>> both the header files and the matching binary. > > It seems like you want to move headers from the coreboot into the blobs > directory? I don't really see the point in that either. Headers are source, > they need to be covered under the GPL... it's easier to make that clear > when they are in coreboot. I agree with your point that headers and blobs > should always be updated together, but we can still enforce that across two > repositories. Ack. It's technically the same if you change a pointer to both or change the pointer to the binary together with the header files in one commit. But it's easier to make mistakes in the latter case. (I might be too biased here as I've seen too much chaos with these things.) > >>>> Unless a pointer as described above exists for a given plat- >>>> form that relies on a blob, all changes* to that platform >>>> *shall* be refused. > > I think this is counter-productive, as is removing any old boards that > don't comply. I am okay with creating new rules for future platforms, but > there is no reason to throw perfectly good and working boards out just > because they weren't written to comply with something we only just made up. > You wouldn't really be punishing anyone with that (vendors don't care about > outdated chips anyway), you'd just be taking choice away from our users. Well, that's why I brought older Intel based CrOS devices up. I think they are the only ones that currently can't comply. I agree that we should have an exception for older platforms. But it's not really something "just made up", IMHO. Google made their own rules when bringing blobs in with Sandy Bridge, just to break them later. So the problem was obviously already visible when these platforms were added. > > We should continue removing old boards when they become too much of a > maintenance burden, which may happen due to an unmaintainable blob mess, > but we shouldn't categorically remove anything with blobs. > >> OTOH, what's the benefit of maintaining them in the master branch if >> nobody else can do a port with the platform code? > > I think allowing users to build their own custom firmware for an already > supported board is definitely reason enough to keep it in the master > branch. coreboot is not just a project for allowing companies large and > small to build new mainboards... it's also for private enthusiasts that > want to tinker with firmware for a supported board they bought somewhere. While I don't see why that has to happen on the master branch, you have a point there. Let's just say all the `shall`s only apply to binaries released from 4.8 on. > Of course it would be nice if every chipset was implemented well enough > that you can bring up a new mainboard without any help from the vendor, but > that's not always that simple, and I don't think it should be a requirement > for inclusion. Sorry, I thought that is what free software is about. Must have been confused to mix that up with coreboot. IMO, blobs are already a huge offense, a disgrace of coreboot and the GPL. But having to sign an NDA to be able to use a GPL licensed project in a product? WTF?!? I don't care if people think that their loopholes are safe enough and use coreboot that way. But why should the community, including many volunteers, maintain that junk on the master branch? If that is the attitude moving forward, maybe we should stop licensing new code under the GPL? Just as a courtesy towards free-software develo- pers. And to make it clear for new contributors what they sign up for. Nico

3 3

Re: [coreboot] FSP 2.0 headers in coreboot
by Nico Huber 08 May '18

08 May '18

On 06.05.2018 00:03, Aaron Durbin wrote: > On Sat, May 5, 2018 at 5:36 AM, Nico Huber <nico.h(a)gmx.de> wrote: >> On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: >>> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui >>> <kakaroto(a)kakaroto.homelinux.net> wrote: >>>> Hi, >>>> >>>> I've just pushed a commit for review on gerrit >>>> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to >>>> open the discussion here on whether the public coreboot code should >>>> have the FSP headers that match the public FSP headers or if they >>>> should match the 'google fsp' headers. >> >> I tried myself before [1] and ran against a wall of lies and broken >> promises. >> >> Roughly: >> >> - July to September/October: I warned Intel about the situation >> over all available channels (Gerrit, different corporate support >> channels, wrote to Vincent who uploaded the first Kabylake FSP >> to GitHub, several laments about the situation on this mailing >> list I guess). >> - After the first Kaby Lake FSP drop on GitHub, Intel commented >> on Gerrit that the headers there are outdated and internal ones >> have to be used. >> - December 11th, Intel commented on Gerrit that everything is sorted >> out. >> - December 13th, Intel painted Kabylake FSP "Gold" with 6 months >> outdated UPDs. >> >>>> >>>> My understanding of the situation is that chromebooks ship with a >>>> google-modified FSP image and the fsp headers in coreboot have been >>>> added by google employees even before the FSP was officially made >>>> public by Intel. I also somewhat understood that the fsp headers in >>>> coreboot would not be updated to match the public release because it >>>> would break everyone building coreboot for their chromebooks or >>>> something like that. >>> >>> They aren't modified necessarily. It's more of different views on the >>> same timeline of a development. Granted, the releases are definitely >>> not coordinated. I'm not even sure how/who releases the github >>> blobs/headers on Intel's side. >> >> I have more a feeling that different branches exist. >> >>> >>>> >>>> I'm a bit tired of always having that commit that fixes the header >>>> applied locally in all my branches, and I think that it makes much >>>> more sense for coreboot to have the fsp headers that match the public >>>> release and for the google/chromebook coreboot repository to have the >>>> "non-standard header" committed to it instead. >>>> Worst case scenario, we could add #ifdefs to determine what the >>>> structure contents should be depending on the target platform. >>>> >>>> Maybe everyone will say "of course, that makes sense" or maybe >>>> everyone will say "nope, I disagree", but hopefully we can have the >>>> discussion here (or on gerrit) and decide how to handle this use case. >>>> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are >>>> probably also affected by this mismatch of headers. >>> >>> I think we should have both that can be selected through a Kconfig >>> such that we can bind to the headers correctly. We already had to do >>> that for edk2 issues as well. I can't think of better alternative at >>> the moment that supports both. >> >> You can not just switch headers. As Youness pointed out in his commit, >> UPDs used by coreboot are missing in the public release. We'd clutter >> up the tree with #ifdefs. And once that started, I'm sure, somebody >> will use that as excuse to practice it further. OTOH, we could just >> revert the past 10 months of soc/intel/. The major stakeholders had been >> warned early enough. If somebody gets that through Jenkins, I'll +2. > > The technical challenges of managing different sets of headers doesn't > seem too hard. Things can be isolated fairly easily w.r.t. to the > field mismatches. Code can be co-located to handle such scenarios and > keep it isolated. And who is going to do the work? And who can even tell which sets of header files should be supported by upstream coreboot? Of course we can just fix this instance of the problem and wait for it to happen again... For Youness' request, the Kaby Lake FSP headers, who can tell if Intel isn't going to release another public version with coreboot-matching headers one day after we finished incorporating the old version? I don't think we can solve this by running around and fixing issues that should not exist. We should figure out how to prevent such issues, first. > >> >> Um, a little more serious: I believe the only solution is to enforce >> some sane rules about code changes that depend on blob headers and >> blobbed platforms in general, e.g. (just a draft; but I wouldn't mind >> if we take it verbatim): >> >> (meaning of *shall*, *should* and *recommended* as specified in [2], >> "changes" refer to new commits for the coreboot master branch) >> >> 0. Generally: >> All platforms should be blob-free. >> >> All blobs should be redistributable. >> >> Providers of blobs should sign them and take responsibility >> that the signed blobs were unaltered after compilation (e.g. >> do not contain malware). It is *recommended* that the public >> key needed to verify the signature is obtainable through a >> specific channel (e.g. single responsible contact person) >> _independently_ from the blob's distribution path. >> >> 1. After the coreboot 4.8 release: >> All changes to a binary-specific header file (including >> the addition of new files) *shall* be refused, unless a >> matching binary is publicly available. >> >> For each platform that relies on a blob, the coreboot tree >> *should* point (e.g. git submodule) to a commit containing >> both the header files and the matching binary. >> >> 2. After the coreboot 4.9 release: >> For each platform that relies on a blob, the coreboot tree >> *shall* point (e.g. git submodule) to a commit containing >> both the header files and the matching binary. If the plat- >> form code within coreboot supports multiple variants of that >> platform, that commit shall contain all necessary binaries >> for all variants supported by coreboot, all compatible with >> the same header files. >> >> Unless a pointer as described above exists for a given plat- >> form that relies on a blob, all changes* to that platform >> *shall* be refused. >> >> All platforms that rely on a blob that is not redistribu- >> table and whose distribution as an individual file has been >> stopped or has never happened *shall* be immediately removed >> from the master branch. >> >> *excluding changes to maintain tree-wide compatibility >> >> 3. After the coreboot 4.10 release: >> Unless a pointer as described above exists for a given plat- >> form that relies on a blob, that platform *shall* be imme- >> diately removed from the master branch. >> >> Unless a signature as described above exists for a given >> blob, all changes* to platforms that have been launched to >> market and rely on that blob *shall* be refused. Amendment: "for a given blob" that was released after coreboot 4.10 >> >> This should give everybody enough time to adapt and the refusal to >> merge new patches should constantly remind them so they won't >> forget the matter and panic right before a release. >> >> One reason for not writing this up earlier is that it potentially >> hits a lot of CrOS devices. Though, in the proposed scheme there'd >> still be 6 months for Google to figure things out. > > It's just not Google who can sign up for such things. There are legal > agreements about some of the points above that may make it completely > infeasible to meet. As you pointed out there is 6 months, but > contracts would have to be renegotiated. I assume we are talking about the CrOS devices with mrc.bin (Haswell, Broadwell, BayTrail)? I know the situation must be awkward for those. OTOH, what's the benefit of maintaining them in the master branch if nobody else can do a port with the platform code? NB: Funny legal interpretation, IANAL: If I wanted to make a product based on Broadwell with upstream coreboot, it would be illegal here in Germany _without_ reverse engineering the blobs first (unless I can get the sources for the blob in a legal way and get them to com- pile, which I estimate would be more work). > > I'm curious how you want things to play out from above. Could you > provide how you think things will look over time? I think mostly the process of adding and developing new platforms would have to change. Instead of pushing useless headers to coreboot.git, one would have to push headers+binaries to another repo instead (can be anywhere as long as it's public) and change a pointer in coreboot.git. Some older unmaintained platforms would vanish, I guess. Though, I doubt there is much to do to fix them (beside CrOS devices where no public blobs exist). To save an older platform, headers and blobs would have to move to a common location. I have to admit I didn't think the demanding of signed blobs through. There would have to be an exception for older unmaintained blobs. > This isn't just > impacting recent and new Intel platforms. There are other vendors > beside Intel. I was told often that we have the blobs from other vendors in our 3rdparty/blobs repo. It's just the headers that would have to move. > I'm trying to understand what platforms would be > supported in practice on coreboot. All of them, I hope. AFAICS, public binaries already exist for all but the Intel+CrOS combination. Why should that be so hard to change? Everything else seems to be either redistributable, already in our 3rdparty/blobs repo (so I was told) or (in case of FSP) sits in a GitHub repo where commits with headers+binaries already exist. Nico >> [1] https://review.coreboot.org/#/c/coreboot/+/20477/ >> [2] http://www.ietf.org/rfc/rfc2119.txt

2 1

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)
by Ivan Ivanov 08 May '18

08 May '18

Just noticed your another message. Reposting it just in case it didn't reach Jonathan: Kyösti Mälkki wrote: Right.. I ack the no-go. Try if DEBUG_CAR=y (could be in menuconfig) works before/after the regression commit. My guess is it fails in cpu/amd/car/post_cache_as_ram.c:101, that's about the first place where car_get_var() goes wrong on systems with LATE_CBMEM_INIT. IMHO it should not even have built when there is any CAR_GLOBAL symbol present. I would rather not see any EARLY_CBMEM_INIT or LATE_CBMEM_INIT tests added to the tree today. Those K8 were meant to be left behind last October. Once they are all removed from master, fixing those "*.c" includes and CAR migration can bring your board back... 2018-05-08 11:37 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: > Sadly it turned out that didn't help to Jonathan: > > I'm skeptical this will address my issue on msi/ms7135, as it's a > Socket 754 board that only single-core CPU packages are available for. > Nevertheless, I'll give this change a try. > > Indeed, it does not fix the issue I'm having. > > > 2018-05-06 8:22 GMT+03:00 Kyösti Mälkki <kyosti.malkki(a)gmail.com>: >> On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot >> <coreboot(a)coreboot.org> wrote: >>> On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch >>> <jakllsch(a)kollasch.net> wrote: >>>> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: >>>>> Hi Aaron, >>>>> I tried to boot PC Engines apu2 on recent master branch and discovered >>>>> that it not boot. Bisection points to: >>>>> >>>>> 60320182d011 console: only allow console messages after initialization >>>>> >>>>> It is hard to believe that this change cause AGESA reset loop, but I >>>>> checked 3 times. After applying above commit I end up with loop: >>>> >>>> I see a similar romstage boot loop starting with this commit on >>>> msi/ms7135 (K8N Neo3), a DDR1 K8 board. >>> >>> I think it's the AMD boards and their weird config. CAR_GLOBAL is >>> used, but apparently these boards fail if accessing CAR_GLOBAL at the >>> wrong time? If you have log diffs w/ and w/o the patch it'd help with >>> root cause. >>> >> >> Jonathan, try this: https://review.coreboot.org/c/coreboot/+/26120 >> >> Kyösti >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)
by Ivan Ivanov 08 May '18

08 May '18

Sadly it turned out that didn't help to Jonathan: I'm skeptical this will address my issue on msi/ms7135, as it's a Socket 754 board that only single-core CPU packages are available for. Nevertheless, I'll give this change a try. Indeed, it does not fix the issue I'm having. 2018-05-06 8:22 GMT+03:00 Kyösti Mälkki <kyosti.malkki(a)gmail.com>: > On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot > <coreboot(a)coreboot.org> wrote: >> On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch >> <jakllsch(a)kollasch.net> wrote: >>> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: >>>> Hi Aaron, >>>> I tried to boot PC Engines apu2 on recent master branch and discovered >>>> that it not boot. Bisection points to: >>>> >>>> 60320182d011 console: only allow console messages after initialization >>>> >>>> It is hard to believe that this change cause AGESA reset loop, but I >>>> checked 3 times. After applying above commit I end up with loop: >>> >>> I see a similar romstage boot loop starting with this commit on >>> msi/ms7135 (K8N Neo3), a DDR1 K8 board. >> >> I think it's the AMD boards and their weird config. CAR_GLOBAL is >> used, but apparently these boards fail if accessing CAR_GLOBAL at the >> wrong time? If you have log diffs w/ and w/o the patch it'd help with >> root cause. >> > > Jonathan, try this: https://review.coreboot.org/c/coreboot/+/26120 > > Kyösti > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

coreboot release 4.8 - Please help with release notes and testing
by Martin Roth 07 May '18

07 May '18

Just a reminder that we're going to do the release in on May 15, 8 days from now, and we need help with the release notes. I've started them at https://pads.ccc.de/yGXyCFe7g7 and have added a list of commits to the bottom of the document for reference. If you have a favorite commit, or feel that some change is significant enough to mention, please help with the document. Additionally, if you can, please test your boards with the latest commits, and get the platform added to the board-status list. Thanks everyone. Martin

1 0

Re: [coreboot] ACPI error booting Windows
by Alex Feinman 06 May '18

06 May '18

Just to close the thread - I've found the problem. It was a reference to PMIC.OVTH in the mipi camera asl file. I've removed the entire MIPI block for now because my platform does not have a camera, but the underlying issue should be easy to solve if needed ________________________________ From: Matt DeVillier <matt.devillier(a)gmail.com> Sent: Wednesday, April 25, 2018 8:50 PM To: alexfeinman(a)hotmail.com Cc: coreboot Subject: Re: [coreboot] ACPI error booting Windows you can take a look at all my configs as as well as all the patches in my tree in my github there. They aren't all fully up to date, but should be useful. Check Caroline, Cave, Chell, Sentry for Skylake CrOS devices, which should all be the same ACPI-wise as kblrvp3. I haven't pushed the config for the KabyLake CrOS device yet since it's not yet released, but it it doesn't require any additional patches from what's in my tree now. On Wed, Apr 25, 2018 at 9:02 PM Alex Feinman <alexfeinman(a)hotmail.com<mailto:alexfeinman@hotmail.com>> wrote: That unfortunately did not help. Would it be possible to take a look at your .config? Perhaps I'll be able to spot something ________________________________ From: Matt DeVillier <matt.devillier(a)gmail.com<mailto:matt.devillier@gmail.com>> Sent: Wednesday, April 25, 2018 4:14 PM To: alexfeinman(a)hotmail.com<mailto:alexfeinman@hotmail.com> Cc: coreboot Subject: Re: [coreboot] ACPI error booting Windows I have Windows booting on a KBL CrOS device, and looking at my tree, pretty sure the only change I have that would potentially address that error is adding the pcon value to the IGD ACPI OpRegion header: https://github.com/MattDevo/coreboot/commit/3349065354709c85276555516827246… there were a few others but they've all since been merged upstream On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman <alexfeinman(a)hotmail.com<mailto:alexfeinman@hotmail.com>> wrote: I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux runs fine, but when I attempt to install Windows 10 (or boot a preinstalled Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC00000A5). There is a Microsoft document that provides a large amount of possible reasons for this error, however I can't even narrow it down because cleverly Windows 10 no longer prints the bug check parameters, at least not in this case. I would appreciate some pointers if possible. Thank you Alex -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Change in coreboot[master]: console: Skip non-BSP printk() earlier
by Kyösti Mälkki 06 May '18

06 May '18

On Sun, May 6, 2018 at 4:48 PM, Jonathan A. Kollasch (Code Review) <gerrit(a)coreboot.org> wrote: > I'm skeptical this will address my issue on msi/ms7135, as it's a > Socket 754 board that only single-core CPU packages are available > for. Nevertheless, I'll give this change a try. > > Indeed, it does not fix the issue I'm having. > Apologies for the spam/duplicate some may have received, I did not check recipients of the previous post. Right.. I ack the no-go. Try if DEBUG_CAR=y (could be in menuconfig) works before/after the regression commit. My guess is it fails in cpu/amd/car/post_cache_as_ram.c:101, that's about the first place where car_get_var() goes wrong on systems with LATE_CBMEM_INIT. IMHO it should not even have built when there is any CAR_GLOBAL symbol present. I would rather not see any EARLY_CBMEM_INIT or LATE_CBMEM_INIT tests added to the tree today. Those K8 were meant to be left behind last October. Once they are all removed from master, fixing those "*.c" includes and CAR migration can bring your board back...

1 0

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)
by Kyösti Mälkki 05 May '18

05 May '18

On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot <coreboot(a)coreboot.org> wrote: > On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch > <jakllsch(a)kollasch.net> wrote: >> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: >>> Hi Aaron, >>> I tried to boot PC Engines apu2 on recent master branch and discovered >>> that it not boot. Bisection points to: >>> >>> 60320182d011 console: only allow console messages after initialization >>> >>> It is hard to believe that this change cause AGESA reset loop, but I >>> checked 3 times. After applying above commit I end up with loop: >> >> I see a similar romstage boot loop starting with this commit on >> msi/ms7135 (K8N Neo3), a DDR1 K8 board. > > I think it's the AMD boards and their weird config. CAR_GLOBAL is > used, but apparently these boards fail if accessing CAR_GLOBAL at the > wrong time? If you have log diffs w/ and w/o the patch it'd help with > root cause. > Jonathan, try this: https://review.coreboot.org/c/coreboot/+/26120 Kyösti

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2018