[coreboot] Re: Mainboard porting assistance
Sorry, I'll commit this instead of continuing to post here but I thought that I should add that the diff is useless too. On Wed., 18 Sep. 2019, 8:40 pm Angel Pons, wrote: > Hi Benjamin, > > Yes, the link was moved there the other day. > > Best regards, > > Angel > > On Wed, Sep 18, 2019, 12:34 Benjamin Doron > wrote: > >> Angel, the link you sent is unavailable now, but is the gist of it that I >> attempt to commit and Gerrit automatically puts it into review? >> >> Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where >> the link was moved? >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMD AGESA maintenance and/or deprecation
On Thu, Sep 19, 2019 at 3:20 AM Matt B wrote: > > > Kyösti Mälkki said: >> >> AFAICS, that platform codebase even suffers from cache coherency issues >> while executing from cache-as-ram; there has been indications that increased >> spinlock usage in romstage causes boot failures and/or reset loops. > > > Where do you see this? Has it been reported? It was the plausible reason for the revert: https://review.coreboot.org/c/coreboot/+/30830 where seemingly legit code change trigger bugs. Like with many RAM related problems on same platform(s) running with upstream coreboot, those with hardware have not bisected or debugged this further to have definite answers. I can tell AGESA fam14 has issues with AP's accessing CAR. >> Implementation of HyperTransport requires maintaining some pretty strange >> (or poor-quality) code for both static devicetree and PCI subsystem. > > > Which code? How can it be improved? Unless platform meets release requirements, there will be a commit to remove offending/bad code with explanations. As noted earlier, pretty much none of the promises from last five years to debug/bisect/improve, by various people on the mailing list, have not been fulfilled. My goodwill with fam10-15 is long gone. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMD AGESA maintenance and/or deprecation
Kyösti Mälkki said: > AFAICS, that platform codebase even suffers from cache coherency issues > while executing from cache-as-ram; there has been indications that > increased spinlock usage in romstage causes boot failures and/or reset > loops. > Where do you see this? Has it been reported? Implementation of HyperTransport requires maintaining some pretty strange > (or poor-quality) code for both static devicetree and PCI subsystem. > Which code? How can it be improved? Sincerely, -Matthew Bradley On Wed, Sep 18, 2019 at 6:25 PM Kyösti Mälkki wrote: > On Thu, Sep 19, 2019 at 1:05 AM Martin Roth wrote: > > > > My proposal is to drop platforms that aren't being tested, aren't > > being maintained, or are causing serious problems with general > > coreboot development. > > > > For example > > - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest > > dropping that code, even though it apparently doesn't support S3, so > > it was suggested that we drop it. S3 isn't used heavily on servers, > > so personally I don't think it matters. > > Nothing to do with S3 for asus/kgpe-d16 deprecation. > > Platform code (non-AGESA) fam10-15 does not meet 3 of the 3 announced > requirements for next release. Should someone want to maintain > kgpe-d16 on master branch, the decisions on those release requirements > will need to be officially withdrawn. AFAICS, that platform codebase > even suffers from cache coherency issues while executing from > cache-as-ram; there has been indications that increased spinlock usage > in romstage causes boot failures and/or reset loops. > > Implementation of HyperTransport requires maintaining some pretty > strange (or poor-quality) code for both static devicetree and PCI > subsystem. > > Regards, > Kyösti Mälkki > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMD AGESA maintenance and/or deprecation
On Thu, Sep 19, 2019 at 1:05 AM Martin Roth wrote: > > My proposal is to drop platforms that aren't being tested, aren't > being maintained, or are causing serious problems with general > coreboot development. > > For example > - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest > dropping that code, even though it apparently doesn't support S3, so > it was suggested that we drop it. S3 isn't used heavily on servers, > so personally I don't think it matters. Nothing to do with S3 for asus/kgpe-d16 deprecation. Platform code (non-AGESA) fam10-15 does not meet 3 of the 3 announced requirements for next release. Should someone want to maintain kgpe-d16 on master branch, the decisions on those release requirements will need to be officially withdrawn. AFAICS, that platform codebase even suffers from cache coherency issues while executing from cache-as-ram; there has been indications that increased spinlock usage in romstage causes boot failures and/or reset loops. Implementation of HyperTransport requires maintaining some pretty strange (or poor-quality) code for both static devicetree and PCI subsystem. Regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What are splitted / several flash ROMs about?
Hi Philipp, there is some documentation you might have missed [1] (can't blame you, the index is broken [2]). On 18.09.19 23:23, Philipp Stanner wrote: > Am Montag, den 16.09.2019, 07:20 -0700 schrieb Stefan Reinauer: >> Yes, this is often done as a cost reduction method. The habit started >> with the arrival of the ME and the firmware descriptor allowing you >> to spread your different firmware regions across one or both chips. > > Hm, surprises me. Normally, in technology one big thing is cheaper – a > large container ship instead of several small ones, one big hard drive > instead of two small ones. And in this case they need some hardware > mechanism concatenating the chips; this had to be developed first etc. The opposite seems true if you consider that these chips are at the limit of the current technology. A better comparison would be a high end processor, 16 cores might cost you three times as much as 8 cores in the same package. > >> The tool ifdtool will help you analyze images for Intel firmware >> descriptors. >> Sounds like in this case ME and the other regions live in the larger >> chip, allowing the smaller chip to be fully used for system firmware. >> If that's the case, erasing the larger chip will brick your system. >> Better do some analysis first. > > Ok, just to confirm: > I have to analyze which part of the firmware + ME lays where. > If the ME lays partly on the second chip (and I want to strip it), I > have to extract both images – and flash both chips again so that the > IME lays at the same offsets? I didn't fully understand how the flash > descriptors work so far. See documentation ^ > > If the ME lays on the first chip and coreboot fits into it with the > stripped ME, I could erase the second chip – but don't really have to, > because if there's no ME code on it, whatever lays there will not be > executed again after flashing? That question can only be answered if we'd assume absence of all bugs (otherwise, "will not be executed" becomes "shouldn't be executed"). If you erase it, you can be sure. If you don't, and some dormant code gets activated, you can never tell if it was an accident or a sophis- ticated backdoor. In case, if you want to put coreboot into the first chip, you'll have to adapt the descriptor layout. coreboot needs to reside at the top (highest address) of the BIOS region. Nico [1] https://doc.coreboot.org/mainboard/lenovo/xx30_series.html [2] https://review.coreboot.org/c/coreboot/+/35462 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMD AGESA maintenance and/or deprecation
My proposal is to drop platforms that aren't being tested, aren't being maintained, or are causing serious problems with general coreboot development. For example - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest dropping that code, even though it apparently doesn't support S3, so it was suggested that we drop it. S3 isn't used heavily on servers, so personally I don't think it matters. - The ONLY platform that supports AGESA f12h is torpedo, and it's never been tested, so I'd like to suggest again that it get dropped. - Family 14h is very well tested, with regular testing happening. Do not drop. -- pcengines/apu1/4.9-1870-gd44d4f0f4e/2019-06-03T10_14_06Z -- asrock/e350m1/4.9-2228-gce4d39d2d7/2019-06-29T00_31_14Z - The last time a family 15tn board was tested was in 2019. Do not drop. -- lenovo/g505s/4.9-8-g42d1660/2018-12-21T00_01_02Z - The last time Family16KB was tested was in mid 2018. If it doesn't get tested again by mid 2020, I think we should consider dropping it then. -- asus/am1i-a/4.7-988-ge93634caa0/2018-05-03T08_29_12Z The initial reason we wanted to leave AMD vendorcode alone (8 years ago) was because we hoped that AMD would update it. That hasn't happened, so I've already told several people that they're welcome to make whatever changes they feel are needed. Martin On Thu, Sep 12, 2019 at 10:42 AM Patrick Georgi wrote: > > On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote: > > Would "some people" or these "advocates" be willing to elaborate? > I CC'd Nico and Martin because I seem to remember that we talked > about AGESA (and its quality and/or life cycle). Nico, for example, > seems to advocate scrapping AGESA to replace it with a rewrite ;-) > > > I would say >50% of our MAINTAINERS file is just bogus when it comes > > to working through issues. > Which is something we're trying to improve. > > > As an active topic, I don't see > > anybody at Intel willing to discuss the topic of how hiding PCI > > devices may brake PCI compliance and generally several assumptions in > > coreboot PCI subsystem. > It's unlikely that they'll find your request hidden in this thread, > which is about something very much outside their domain, so please > start a discussion separately and maybe Cc the people closest to > being maintainers for that part of the code (e.g. affected SoC)? > > > Do you want to extend this with c) coverity scan over vendorcode/ ? > Sorry if I wasn't as clear on this as I wanted to be: I'm not > saying that "it's ugly in Coverity means we'll drop the code", but > we have a couple of folks complaining about AGESA code quality like > all. the. time (e.g. Nico?), and during Jacob's GSoC there was some > talk about how it's unclear how long that code will remain in the > tree anyway (I think Martin can chime in on this). > > As I'm working through Coverity, that was brought back to my attention > and I thought about thinking about that. Also, if somebody wants > to step up as maintainer, Coverity provides a pretty good set of > bite-sized tasks that walk you through the code area of interest > indiscriminately. > > We said to leave vendorcode alone, but that was under the assumption > that it's maintained from some upstream source. Our AGESA sources > quite obviously aren't, so why not open them up to development > (including clean up) some more? > > > Reference to some already existing gerrit comments or mailing list posts > > would be nice. > Mostly chatter on IRC, to be honest. Part of the intent of this mail > was to surface this more officially. > > > AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of the next > > release and is already at CAR_GLOBAL_MIGRATION=n. > Well, that's good news! > > > The timeframe for dropping entire platforms has previously > > been couple releases or couple years, > No change intended here. I mostly wanted to avoid bringing this up > formally just days before the intended removal (from feedback on the > removals in 4.10, people don't seem to notice out various deprecation > notices but only when stuff is gone). > > This was about surfacing issues like these earlier, to reduce the amount of > surprise. Having your status update on the C bootblock and CAR migration > implementation is useful for that, too! > > > you are making it sound like you want to drop AGESA vendorcode > > like tomorrow. > I'm sorry to have made that impression. That's definitely not what I was > proposing. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What are splitted / several flash ROMs about?
Am Montag, den 16.09.2019, 07:20 -0700 schrieb Stefan Reinauer: > Yes, this is often done as a cost reduction method. The habit started > with the arrival of the ME and the firmware descriptor allowing you > to spread your different firmware regions across one or both chips. Hm, surprises me. Normally, in technology one big thing is cheaper – a large container ship instead of several small ones, one big hard drive instead of two small ones. And in this case they need some hardware mechanism concatenating the chips; this had to be developed first etc. But hey, the manufacturer's ways are unpredictable ^^ > The tool ifdtool will help you analyze images for Intel firmware > descriptors. > Sounds like in this case ME and the other regions live in the larger > chip, allowing the smaller chip to be fully used for system firmware. > If that's the case, erasing the larger chip will brick your system. > Better do some analysis first. Ok, just to confirm: I have to analyze which part of the firmware + ME lays where. If the ME lays partly on the second chip (and I want to strip it), I have to extract both images – and flash both chips again so that the IME lays at the same offsets? I didn't fully understand how the flash descriptors work so far. If the ME lays on the first chip and coreboot fits into it with the stripped ME, I could erase the second chip – but don't really have to, because if there's no ME code on it, whatever lays there will not be executed again after flashing? P. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
This Panic i got in the past two. Try building coreboot without Microcode included and load microcode via kernel (you need non-free repo for that) Would be interessting if you than also my Error. If so i can send you a deb-package with a working kernel with SLAB allocator. Am 18.09.19 um 15:53 schrieb Merlin Büge: > Hi, > > > maybe related: > > With coreboot master (as of 20190916), 4.10 and 4.9 (compiled on Debian > 10) I get kernel panics, too. Log and config attached. There is one > Opteron 6328 installed in the KGPE-D16. I'm using the GRUB2 payload > (which runs fine). I don't know what's causing this, I just want to > provide another data point. > > coreboot 4.8 and 4.8.1 were not able to load my payload (same config). > For reference, I also attached the logs of that. > > Finally, coreboot commit b1d26f0e92 from mid 2018 worked for me. > > > Cheers, > > Merlin > > > > > On Wed, 18 Sep 2019 14:22:23 +0200 > Kinky Nekoboi wrote: > >> Highly appreciating that afford. >> >> Would like to mention Problems with Current Linux kernel with this Board. >> >> ( The SLUB Allocator is causing panics at boot for my builds) >> >> Pls see: >> >> https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html >> >> >> >>> Hi all, >>> we see a lot of attention around KGPE-D16 maintainership problems. >>> After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb >>> decided to help in maintaining that platform by organizing crowd >>> founding campaign or getting founds in other ways (direct sponsors). >>> >>> Since we are based in Poland there is chance that even with small >>> contribution from community we would be able to cover the costs. >>> >>> Ideal plan would be to have structure similar to what we maintain for >>> PC Engines: >>> https://pcengines.github.io/ >>> Where we providing signed and reproducible binaries every month and >>> keep as close to mainline as possible. Of course if development will >>> be active, then there always would be delta of patches held in review. >>> >>> Unfortunately we don't have hardware. During OSFC 2019 Stefan left one >>> board, but it was too late (and probably too expensive) for us to >>> organize any shipment to Poland. We looking to have 2 mainboards one >>> for development and one in our automated regression testing >>> environment. Of course we will start even with just one. >>> >>> If anyone is willing to help in founding, sponsoring hardware or by >>> code development and testing we would be very grateful. >>> >>> Please copy other people and share this post wherever is necessary to >>> keep this platform alive. Positive feedback will help things rolling. >>> >>> Best Regards, >>> ___ > coreboot mailing list -- >>> coreboot@coreboot.org > To unsubscribe send >> an email to coreboot-le...@coreboot.org > > signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
Hi, maybe related: With coreboot master (as of 20190916), 4.10 and 4.9 (compiled on Debian 10) I get kernel panics, too. Log and config attached. There is one Opteron 6328 installed in the KGPE-D16. I'm using the GRUB2 payload (which runs fine). I don't know what's causing this, I just want to provide another data point. coreboot 4.8 and 4.8.1 were not able to load my payload (same config). For reference, I also attached the logs of that. Finally, coreboot commit b1d26f0e92 from mid 2018 worked for me. Cheers, Merlin On Wed, 18 Sep 2019 14:22:23 +0200 Kinky Nekoboi wrote: > Highly appreciating that afford. > > Would like to mention Problems with Current Linux kernel with this Board. > > ( The SLUB Allocator is causing panics at boot for my builds) > > Pls see: > > https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html > > > > > Hi all, > > we see a lot of attention around KGPE-D16 maintainership problems. > > After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb > > decided to help in maintaining that platform by organizing crowd > > founding campaign or getting founds in other ways (direct sponsors). > > > > Since we are based in Poland there is chance that even with small > > contribution from community we would be able to cover the costs. > > > > Ideal plan would be to have structure similar to what we maintain for > > PC Engines: > > https://pcengines.github.io/ > > Where we providing signed and reproducible binaries every month and > > keep as close to mainline as possible. Of course if development will > > be active, then there always would be delta of patches held in review. > > > > Unfortunately we don't have hardware. During OSFC 2019 Stefan left one > > board, but it was too late (and probably too expensive) for us to > > organize any shipment to Poland. We looking to have 2 mainboards one > > for development and one in our automated regression testing > > environment. Of course we will start even with just one. > > > > If anyone is willing to help in founding, sponsoring hardware or by > > code development and testing we would be very grateful. > > > > Please copy other people and share this post wherever is necessary to > > keep this platform alive. Positive feedback will help things rolling. > > > > Best Regards, > > ___ > coreboot mailing list -- > > coreboot@coreboot.org > To unsubscribe send > an email to coreboot-le...@coreboot.org -- Merlin Büge defconfig Description: Binary data cb4.10_linuxkernel_panic_log Description: Binary data cb4.8.1_payload_not_loaded_log Description: Binary data cb4.8_payload_not_loaded_log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: KGPE-D16 maintainership
Highly appreciating that afford. Would like to mention Problems with Current Linux kernel with this Board. ( The SLUB Allocator is causing panics at boot for my builds) Pls see: https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html > Hi all, > we see a lot of attention around KGPE-D16 maintainership problems. > After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb > decided to help in maintaining that platform by organizing crowd > founding campaign or getting founds in other ways (direct sponsors). > > Since we are based in Poland there is chance that even with small > contribution from community we would be able to cover the costs. > > Ideal plan would be to have structure similar to what we maintain for > PC Engines: > https://pcengines.github.io/ > Where we providing signed and reproducible binaries every month and > keep as close to mainline as possible. Of course if development will > be active, then there always would be delta of patches held in review. > > Unfortunately we don't have hardware. During OSFC 2019 Stefan left one > board, but it was too late (and probably too expensive) for us to > organize any shipment to Poland. We looking to have 2 mainboards one > for development and one in our automated regression testing > environment. Of course we will start even with just one. > > If anyone is willing to help in founding, sponsoring hardware or by > code development and testing we would be very grateful. > > Please copy other people and share this post wherever is necessary to > keep this platform alive. Positive feedback will help things rolling. > > Best Regards, > ___ > coreboot mailing list -- > coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
Benjamin Doron schrieb am Mi., 18. Sep. 2019, 12:34: > Angel, the link you sent is unavailable now, but is the gist of it that I > attempt to commit and Gerrit automatically puts it into review? > > Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where > the link was moved? > Yes, that's the same document. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
Hi Benjamin, Yes, the link was moved there the other day. Best regards, Angel On Wed, Sep 18, 2019, 12:34 Benjamin Doron wrote: > Angel, the link you sent is unavailable now, but is the gist of it that I > attempt to commit and Gerrit automatically puts it into review? > > Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where > the link was moved? > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
Angel, the link you sent is unavailable now, but is the gist of it that I attempt to commit and Gerrit automatically puts it into review? Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where the link was moved? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Mainboard porting assistance
For some reason, the console log that I attempted to attach did not seem to
reach the list. I'll paste it here:
"coreboot-4.10-528-g809b7513a2-2.0-beta1 Mon Sep 2 20:08:20 UTC 2019 bootblock
starting (log level: 7)...
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
CPU: ID 406e3, Skylake D0, ucode: 00cb
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1904 (rev 08) is Skylake-U
PCH: device id 9d48 (rev 21) is Skylake-U Premium
IGD: device id 1916 (rev 07) is Skylake ULT GT2
misccfg_mask:fff000ff misccfg_value:43200
CBFS: 'Master Header Locator' located CBFS at [270200:80)
CBFS: Locating 'fallback/romstage'
CBFS: Found @ offset 80 size b3cc" (many null characters follow, but this is
the end of the log)
I looked into FSP-T (TempRamInit on FSP 2.0) and apparently it does not support
Skylake. That shouldn't be a problem, I've seen some laptops supported by
coreboot using its 'common' cache-as-RAM, but it made me more certain that it's
my romstage code at fault (FSP-T isn't needed, coreboot works on these laptops,
etc).
I ended up investigating romstage.c + pei_data.c vs only romstage.c to discover
that the former was deprecated and that ultimately, the code that I had been
using for romstage.c with FSP 2.0 may have been a leftover from when I had been
trying to use FSP 1.1. I'll paste a diff below in case it helps/anyone is
interested.
"--- thenromstage.c 2019-09-18 15:18:13.165824532 +1000
+++ romstage.c 2019-09-17 19:26:56.417327000 +1000
@@ -16,12 +16,12 @@
* GNU General Public License for more details.
*/
-#include
#include
#include
#include
+#include
-static void mainboard_fill_dq_map_data(void *dq_map_ch0, void *dq_map_ch1)
+static void mainboard_fill_dq_map_data(void *dq_map_ptr)
{
/* DQ byte map */
const u8 dq_map[2][12] = {
@@ -29,18 +29,16 @@
0x0F, 0x00, 0xFF, 0x00, 0xFF, 0x00 },
{ 0x33, 0xCC, 0x00, 0xCC, 0x33, 0xCC,
0x33, 0x00, 0xFF, 0x00, 0xFF, 0x00 } };
- memcpy(dq_map_ch0, dq_map[0], sizeof(dq_map[0]));
- memcpy(dq_map_ch1, dq_map[1], sizeof(dq_map[1]));
+ memcpy(dq_map_ptr, dq_map, sizeof(dq_map));
}
-static void mainboard_fill_dqs_map_data(void *dqs_map_ch0, void *dqs_map_ch1)
+static void mainboard_fill_dqs_map_data(void *dqs_map_ptr)
{
/* DQS CPU<>DRAM map */
const u8 dqs_map[2][8] = {
{ 0, 1, 3, 2, 4, 5, 6, 7 },
{ 1, 0, 4, 5, 2, 3, 6, 7 } };
- memcpy(dqs_map_ch0, dqs_map[0], sizeof(dqs_map[0]));
- memcpy(dqs_map_ch1, dqs_map[1], sizeof(dqs_map[1]));
+ memcpy(dqs_map_ptr, dqs_map, sizeof(dqs_map));
}
static void mainboard_fill_rcomp_res_data(void *rcomp_ptr)
@@ -70,10 +68,8 @@
dump_spd_info();
assert(blk.spd_array[0][0] != 0);
- mainboard_fill_dq_map_data(_cfg->DqByteMapCh0,
- _cfg->DqByteMapCh1);
- mainboard_fill_dqs_map_data(_cfg->DqsMapCpu2DramCh0,
- _cfg->DqsMapCpu2DramCh1);
+ mainboard_fill_dq_map_data(_cfg->DqByteMapCh0);
+ mainboard_fill_dqs_map_data(_cfg->DqsMapCpu2DramCh0);
mainboard_fill_rcomp_res_data(_cfg->RcompResistor);
mainboard_fill_rcomp_strength_data(_cfg->RcompTarget);
"
While I unfortunately can't test anything for the moment because my Pi is out
of commission, I'll reconfigure the devicetree based on values extracted from
the OEM's BIOS and hope that this gets me a somewhat working port.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."
On 17.09.19 17:28, Denis 'GNUtoo' Carikli wrote: > On Tue, 17 Sep 2019 10:21:38 +0200 Raw card type:D > Is there more information on such "card type" somewhere? JEDEC specifies these reference cards. Sometimes you can get their specification for free (need to register to their webpage, though), sometimes they want money, I fail to see a pattern in what they publish. In theory, there's a good chance that we could fix the training for type D. Though, I can't tell if there are more issues lurking than the failing read training. > Is there a way to avoid buying such "card type"? I fear, no. Unless you can find somebody who already has a specific DIMM model and can ask them for the SPD data. There are even more obvious specs that break compatibility, but the vendors won't tell you. It's really weird. If you ask me, the whole DIMM industry is broken. Instead of documenting their DIMMs and what the boards require, they publish QVLs? It's nuts. Maybe they just fear that customers could realize that DIMMs of one vendor are replaceable with those of another (they are, if they don't violate the spec). Now I wonder, if, or why if not, somebody started a public database of SPD data? > >> last time we encountered problems with type D DIMMs, we concluded that >> it's not supposed to work [1]. Can you confirm if your DIMMs are >> stable with the vendor BIOS? > I didn't try with the stock BIOS on a Thinkpad X200 yet, but I tried > with the stock BIOS on a Thinkpad X200 Tablet and it didn't work. > >> We should probably issue a warning when type D is installed. > Is there also a way or place where to issue warnings to people before > they buy and install such cards? Is doc.coreboot.org for users too? Yes, you can just push changes (under Documentation/ in the coreboot source repo) for review. Maybe a central GM45 page and a link to that for each board? I can write down the limits of the memory controller / raminit code, but as mentioned above, it will be hard to match that to actual DIMMs. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
