Hello Jonathan,
Your response surely came as a blessing ... reading it halfway through, I
was just about to throw the towel, but when I read the rest, it truly made
my day. So it must have been just recently, that the coreboot support for
the AMD K8 (Fam0Fh) was deprecated, as the board is listed in the latest,
4.8 stable release. Oh well, at least for me it's no harm done, as it never
was my intention to dabble in coreboot, only to keep those 2nd Gen Opterons
in the Ultra 40 M2's sockets ... I just somehow overlooked the "K8 only"
neon sign, tying together two stories that could have been a >marriage made
in heaven<, but apparently the merging of two worlds never really happened -
the actual Sun Ultra 40 M2 coreboot port, and the yearnings of Sun Ultra 40
M2 owners from years ago, voicing high hopes in the coreboot project, to
bring the 4 and 6-Core K10 Opteron support to life. My imagination and want
did the rest; I never once questioned the K10, for being supported or not by
the coreboot port, although the absence of any reference in your board
status table was a bit odd, now that I think about it (!).
First and foremost - I would be delighted to try out your latest K10/Fam10h
port, to flash it on my yet to be purchased Ultra 40 M2 machine. I would be
also keen to know, which Quad-Core Opterons did you use for testing (or you
still use), as I'm in no position to gamble with something untested ...
unless you can reassure me that it doesn't really matter, which K10 Opterons
I choose for playing (Barcelona, Shanghai, Instanbul - be it regular of High
Efficiency variants). If you decide to push your "Ultra 40 M2 - Fam10h" Port
to some public place (like GitHub), that would be great. if you're not
inclined to do that at this stage, then I'd be grateful for some other
arrangements, until you decide what to do with your port, in reference to
official coreboot project.
There's only one "small" problem ... before I'm competent enough, to either
talk or do anything coreboot related, I'll have to learn to crawl and walk
first, or so it seems (have a look at my response to David). Browsing
through available coreboot documentation it suddenly dawned on me, that I
may not be nearly enough qualified, to even start with the work (flash the
coreboot image onto existing or blank BIOS chip), let alone do some
customizations, or contribute the relevant test results. I really don't want
to surrender, not after I got so excited about doing this, but unless I
receive some additional guidance (links, directions...), I'm pretty much
stuck in the mud.
Looking forward ...
Kind regards,
Bostjan
Hello David,
First of all I'd like to thank you for your reassurance, that I seem to be
on the right path towards the ultimate goal - having a coreboot flashed onto
a marvelous piece of technology (Sun U40 M2), that was retired (IMHO) way
prematurely by the profit driven minds (lacking any spirit) , instead of
being revived by, first - the updated firmware (to support Fam10h), and
second - being overhauled for the new decade (say - Sun Ultra 40 M3, with
either socket C32 or G32 Opterons, or Xeons CPUs). I'm aslo grateful for
your guidelines, about how to go about with testing the board, with a newly
flashed BIOS image.
Today I finally set myself to go through all the available documentation
(old and new coreboot site); after a couple of hours of searching and
reading (no exaggeration here), I was horrified when I realized, that I
don't have the slightest clue, where to start and how to get it done. I felt
like chasing my tail till my head started to spin, or ... like standing at
the foot of the mountain wall I decided to climb, as I've been told it's no
big deal to do it, but nobody told me that the climb starts with a sheer
granite 10m vertical pitch, with hardly any miniscule features to step on or
hold on to. If nobody shows me where to put my feet and fingers on this
featureless granite slab, I might end up standing in front of it forever,
watching hopelessly the easier sections of the route higher above.
What I'm saying is ... I can't seem to find the step-by-step tutorials, for
the "regular Joe" like myself, facing rather common scenario and set of
objectives. For example:
. I have a Sun Ultra 40 M2 machine, I don't like the BIOS on the board (say
- limited range of supported CPUs) ... coreboot to the rescue !
. Next - I will purchase some blank BIOS chips, to use them for flashing the
coreboot BIOS images, just to be on a safe side;
. Once I have the proper coreboot BIOS image file for my board (.rom), I
will search for a suitable external programmer, preferably a USB variety and
brand of decent reputation, supporting the Sun Ultra 40 M2's BIOS chip
package and type. Being supported in Flashrom would be a big bonus, as I
don't have to rely on proprietary flashing tools, not to mention their
questionable support in Linux distros (I'm finally migrating from W* to
Ubuntu, within a week or so;
Example of candidate: >NANO BIOS Programmer<
(http://saishtech.com/blog/nano-usb-bios-programmer/);
. Since there's no such thing as ready made coreboot BIOS image file for my
board, or any other board for that matter, it looks like I'll have to do it
myself. No problem, but . for heaven's sake ... HOW ?
--------
All I could find (and vaguely comprehend) were some bits and fragements that
might or might not be the right ones for me, to teach me in a simple and
concise fashion, tailored for "my kind" of coreboot target group (as in -
not strictly end-users, but miles away from having skills of developers
...), how to do it and what is required, in order to flash the coreboot
image onto BIOS chip, as the final chore on the first day of apprenticeship,
on our beginner's coreboot jorney.
The bits I found, which might (or should) be relevant to get me started:
1.) Coreboot website (Wiki - old):
. >Development / QA< -> >Getting Started<:
https://www.coreboot.org/Lesson1
. >Build HOWTO<:
https://www.coreboot.org/Build_HOWTO
2.) Coreboot website (new):
. Documents: >Welcome to the coreboot documentation< page;
https://doc.coreboot.org/
-> >Getting Started<:
https://doc.coreboot.org/getting_started/index.html
-> >Rookie Guide<:
https://doc.coreboot.org/lessons/index.html
3.) Flashrom:
. Documentation:
https://flashrom.org/Documentation#Using_flashrom
. Supported programmers:
https://flashrom.org/Supported_programmers
. flashrom (8) - Linux Man Pages:
https://www.systutorials.com/docs/linux/man/8-flashrom/
--------
I mentioned the "my kind" of coreboot target group, as I'm absolutely sure
I'm not the only one with this kind of headaches; I'm referring to users
like myself, with seemingly above average computer skills (about motherboard
HW components, BIOS settings, POST codes, BIOS flashing utilities, etc.),
yet this level of knowledge appears to be profoundly inadequate, to get
things done by following the existing coreboot documentation. I find it hard
to believe, that prospective users like myself were not taken into account,
when documentation/tutorials were written. Alongside the existing target
groups - "End Users" (a term a bit deceptive), "Developers" and "OEMs/ODMs",
I reckon there should (ideally) be the fourth group ... let's call it
"Advanced End Users, or "DIY End Users". We do study and learn how to do it,
if we have the precise instructions (step-by-step workflow); we're not
afraid of doing risky things (think: flashing Sun or HP branded SAS HBAs
with LSI Firmware), and above all - we don't moan and whine at the first
obstacle we stumble upon (say, when things don't work exactly as per
instructions, due to crucial procedure step missing). When this happens, we
google the problem or read the manual for the fifteenth time, until we
(hopefully) find the solution or workaround.
What I'm saying David - I would desparately need some directions here, a set
of simplified instructions, from A-to-Z, the real HOW-TO for the coreboot
dummies, to bridge the gap I'm facing right now, before I can advance onto
next stage (for example: learn about payloads and other terms on this level)
and be able to contribute some meaningful test results. I'm not expecting
everything on a silver platter, but what I have available right now, makes
the task at hand an overwhelming challenge.
Looking forward .
Kind regards,
Bostjan
Greetings everyone,
To begin with - I solemnly swear that I did my »homework«, to the best of my abilities, by digging long and hard through all the available sources pertaining the coreboot project (coreboot.org website, mailing lists, announcements, release notes, GitHib pages, etc.). Inspite the wealth of information, I failed to find the answers to my questions.
A brief intro, if I may;
By strict definition of the coreboot project, I'm neither an end-user, nor a developer, even less so an OEM associate/employee … just a »common« user, with just enough expertise in computer HW and SW, to be able to contribute by posting (hopefully) relevant an useful test results. The keyword is »persistence«, the willingness (read: stubborn) to tinker and experiment for hours or days on end, until I get to the bottom of things, or at least try out everything possible, before I surrender unwillingly … for the time being.
I've been following the coreboot project for about two years now (on and off), mainly due to prospect, to get the coreboot flashed onto the board of Sun Ultra 40 M2 workstation, the puchase of which I've been contemplating for a while. The excitement about the coreboot was not just for the sake of getting faster and safer BIOS (not to mention free and open source), but first and foremost to make the Quad and Six-Core Opterons (Barcelona, Shanghai, Instanbul) to work on this board. The last time I checked the status for the Ultra 40 M2 board, on the coreboot project website, there were still quite a few things, marked as either not working, or untested, or as WIP. That wouldn't have bothered me a great deal, if it had not been for the date of the last update, given on the status page - July 2015.
Just recently I started to dig deeper again, into the coreboot documentation and various sources (mostly GitHub). At first, things started to look brighter, when I came accross the 4.3 Release Notes (board officially added to the coreboot), but after some further reading, things pertaining the status of this board got murky and really confusing, to the point that at this moment I have absolutely no idea, whether the board is still supported, and if it isn't, why it was removed. It is still listed in the 4.8_branch on GitHub, but no longer in the Master Branch. I browsed through all the announcements on the relevant coreboot mailing lists (coreboot, coreboot-announce, coreboot-gerrit), but I couldn't find a single word or text line, announcing deprecation of support for the Ultra 40 M2 board.
I'm enclosing a summary of my findings in the document attached, along with the last available status page for the Sun Ultra 40 M2 board, before the coreboot project website was reconstructed, and the status page "Board:sunw/ultra40m2" vanished from the coreboot.org website. Questions that bug me are reaching beyond just "supported" or "not supported", as these terms fail to tell me a number of things. For instance:
1.) Were those »NO«/ »Untested«/ »WIP« fields in the Board:sunw/ultra40m2 status table ever resolved/fixed, before the port was pushed for review and the board got included in the v4.3 ? If not, what functionalities were left unresolved, for the later work (WIP) ?
2.) Was the board confirmed to work with all Quad/Six-Core Opterons (Series 2300 and 2400), or just with a handful of those ? If later, is there a list of tested Opteron CPUs, confirmed to work properly on Ultra 40 M2 board ?
A list of non-working Opterons would be helpful as well, accompanied by at least a short info, explaining why the don't work (or possibly never will, for any given reason).
Looking forward to receive some first-hand insight, about the present-day coreboot status of this Sun board ...
Kind regards,
Bostjan
Thanks Peter,
It doesn't sound half as bad I feared it would, honestly. The way I see it,
this is what I can and should do:
- Acquire the Ultra 40 M2 machine (just bite the bullet, as there's no other
way around.), to be able to run the tests in a first place;
- Buy a couple of blank BIOS chips for that particular board, to use them
for flashing various versions of coreboot BIOS images; if anything goes
terribly wrong (workstation misbehaves, with any given coreboot image
flashed), I can still use the computer with proprietary BIOS.
- Try with the last stable release, where my board is listed as supported
(4.8?), then stick to it if all works well;
- Post the test results for functionalities (hmm, where . through mailing
list ?), that were marked as >Untested</ >Not working</ >WIP<, as listed in
the last update of the table, with a status summary of the board
functionalities, or . ?
As you can see, I'm fumbling around and stumbling quite a bit, being
overwhelmed by the maze of available information on one hand, and the lack
of encouraging up-to-date hints and proofs for the future on the other hand.
I suppose this is where the proverbial line >welcome to the moment< comes
into play.
Kind regards,
Bostjan
Hi Youness,
In general yes, Intel does plan to continue developing of FSP for future platforms. We will make a good faith effort to keep the publically posted FSP binary freshly updated. I would like to caution that as a platform ages, our internal development shifts to newer ones. Accordingly, I would expect the frequency of FSP releases to lengthen as a platform ages.
Thanks,
Nate
-----Original Message-----
From: Youness Alaoui [mailto:kakaroto@kakaroto.homelinux.net]
Sent: Monday, July 16, 2018 12:29 PM
To: Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com>
Cc: coreboot <coreboot(a)coreboot.org>
Subject: Re: [coreboot] Kaby Lake FSP
Hi Nate,
Thanks a lot for listening to our request and taking care of this! I'm happy to see the binaries finally updated and the FSP headers in coreboot having a matching publicly available binary to use.
You've only mentioned Kabylake in your email, is it safe to assume that you'll use these same practices for future platforms as well ?
Thanks,
Youness.
On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L <nathaniel.l.desimone(a)intel.com> wrote:
>
> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/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.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1394268: Possible Control flow issues (DEADCODE)
/src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node()
________________________________________________________________________________________________________
*** CID 1394268: Possible Control flow issues (DEADCODE)
/src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node()
181 }
182
183 // disabled by default for now, does not seem to be needed much?
184 // Automatically tune the ECC byte DLL read offsets
185 // FIXME? allow override of the filtering
186 // FIXME? allow programmatic override, not via envvar?
>>> CID 1394268: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "lmc_config.s.mode32b == 0" inside this statement: "if (do_eccdll && !do_dllro_...".
187 if (do_eccdll && !do_dllro_hw && (lmc_config.s.mode32b == 0)) { // do not do HW-assist twice for ECC
188 BDK_TRACE(DRAM, "N%d: Starting ECC DLL Read Offset Tuning for LMCs\n", node);
189 errs = perform_HW_dll_offset_tuning(node, 2, 8/* ECC bytelane */);
190 BDK_TRACE(DRAM, "N%d: Finished ECC DLL Read Offset Tuning for LMCs, %d errors\n",
191 node, errs);
192 tot_errs += errs;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0...
BDC seems to be turning off properly on my T430. Powertop measurements
indicate ~0.08W power usage improvement with BT toggled off in
GNOME/NetworkManager.
With regards,
Michał
You should include some more details:
* Used Hardware
* Configfile
* Does anything happen when pressing ESC?
* What does "is not installing OS" mean exactly?
Am Montag, den 09.07.2018, 20:06 +0530 schrieb Dhanasekar Jaganathan:
> Hi All,
>
> After including Seabios as a primary bootloader in coreboot, what
> are the
> other option, I suppose to set / enable in core boot menuconfig.
>
> Because, Seabios is not installing OS from USB and I am unable to
> enter
> into seabios Boot menu (after pressing ESC).
>
> Please help me on this.
>
>
> Thanks,
> Dhanasekar
Hi Nate,
Thanks a lot for listening to our request and taking care of this! I'm
happy to see the binaries finally updated and the FSP headers in
coreboot having a matching publicly available binary to use.
You've only mentioned Kabylake in your email, is it safe to assume
that you'll use these same practices for future platforms as well ?
Thanks,
Youness.
On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L
<nathaniel.l.desimone(a)intel.com> wrote:
>
> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus areas is FSP. There was some prior discussion here regarding the lack of public updates for Kaby Lake FSP binaries and headers and questions regarding specialized FSP binaries being built for specific boards. I would like to clear up some of these questions and concerns. We just pushed all of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be forks of Kaby Lake FSP, they are actually just snapshots at different points in time. For example, there is one commit labelled as "Gold release for Kaby Lake FSP" that appears to be special fork for IoT devices... this commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT specific modifications. Apologies for the confusing commit messages and for the temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
