8 Replies Latest reply on Mar 7, 2016 2:30 PM by DrWattsOn

    BIOS updating vs. BIOS breaking

    DrWattsOn

      Hello, I have long heard the story that one should never flash their BIOS unless it is to apply a specific fix to a specific problem.

      Most computers BIOS has to handle a multitude of CPU's and, it seems to me, that can be a major cause of the admonition "If it ain't broke, ..." regarding this subject.

      Meanwhile, I happen to have a computer with the CPU soldered in, and the manufacturer is ...  Intel!

       

      So, on my NUC5i7RYH with it's "embedded" i7 proc, and given that it is a recent design and there have been several (5, I think) BIOS updates issued since I got my

      NUC 6 or 7 months ago. That seems to me like a high rate of tweaking in a short period of time.

       

      So in view of the fact that Intel makes the hardware and software, and they are continuing to produce newer and newer NUC's, I would expect that they are finding ways

      to really improve the product with the frequent BIOS changes. And with the soldered CPU, even though they have different models, still a more stable platform for them

      to work with.

       

      What I am trying to figure out is

      1a: am I correct? EDIT: Is platform stability increased by an embedded CPU?

      And, does platform stability making it easier to nail down and fix BIOS problems?

      1b: what am I overlooking?

      2: should I just go ahead and flash the BIOS? EDIT: Isn't a "prevent defense" better than waiting for bad things to happen?

      3: should all the flashes be performed (in order of course)?

      4: Does this have anything to do with UEFI? EDIT: This part was ANSWERED!

      I have yet to ground my understanding of UEFI vs BIOS. I don't even know EDIT: why my NUC is not set up as UEFI, or should it be, or should I always go with "Legacy"?

      Thanks all for your time even just reading this.

       

      Message was edited by: Mi St  on Feb. 1, 2016, 2:16PM PST (UT-8)

        • 1. Re: BIOS updating vs. BIOS breaking
          allan_intel

          1 and 2. Intel recommends updating the BIOS if you are experiencing an issue that is reported on the list of fixes on the release notes

          https://downloadcenter.intel.com/download/25675/BIOS-Update-RYBDWi35-86A-

          release.PNG

          3. You could update the BIOS only if you have any issues that are fixed on the release notes.

           

          4. The UEFI does not have anything to do with BIOS updates.

           

          Allan.

          • 2. Re: BIOS updating vs. BIOS breaking
            DrWattsOn

            Hi, Allan,

            thanks for the reply and the links to the download BIOS Update353 page with its Read Me and Release Notes pdf's. I will be able to make more intelligent choices with that information.

            Since 354 has been released, I noticed that at the top of that page where it lists the Models of NUC covered, there is a typo: they hit the letter "y" rather than the number "7", ie: NUC5i7...

             

            On my point #1 in my initial post, I believe I was unclear.

            The thing I was seeking confirmation of was whether or not platform stability is greater with a soldered down CPU and the attendant fewer variations of hardware, and whether

            or not that would result in a BIOS for one specific machine being less general in its nature, since it could be written for only one CPU.

             

            And then the point of the rather rapid release of several BIOS Updates within a short period of time, resulting in my inferring they got it wrong in the rush to market,

            and they therefore continued closer examination due to reported problems.

            Kind of like Microsoft and Windows, where they really can never get it right because of so many variables between the machines it is used on.

            Which I think, is one reason Apple's machines need fewer OS updates (besides the fact OS X is BSD based) is they drastically reduced the number of hardware variations.

             

            Additionally I reiterate that not seeing a problem does not mean it isn't lying in wait. My tendency would be to prevent a problem rather than having to fix one, especially if it has significant consequences shortening the computer's lifespan.

            Some (I think it was Toshiba) laptops overheated running Linux because the software that controlled the fan speed and on/off functions, required

            drivers that were unavailable in Linux, so the fan wouldn't turn on.

            If I were to be told that "some people with my model of NUC have this or that problem" that was fixed by a BIOS Update, I would take that as proof that "they" absolutely did "get it wrong" in their first iterations. And I wouldn't want to give any reported problem a chance to manifest on my machine.

            1: Platform stability increased by an embedded CPU?

            2: Platform stability making it easier to nail down and fix BIOS problems?

            3: Isn't a "prevent defense" more sensible?

            4: Isn't such a relatively high rate of issuing BIOS Updates indicative of something? Like maybe lack of due diligence by the involved developers?

            I mean, think of the outcry if they made cars this way ... oh, wait ...

            • 3. Re: BIOS updating vs. BIOS breaking
              venik212

              Clicking on this url produces: PAGE NOT FOUND......   ;-(

              The reason for the rapid fire BIOS release is that there are serious issues with these products-- waking from suspension, booting problems, finicky RAM choices, etc.  Reading through some of the posts here is rather sobering.

              That said, how do I find the latest BIOS for my NUC5i5RYK?

              • 4. Re: BIOS updating vs. BIOS breaking
                allan_intel

                Latest BIOS for NUC5i5RYK : Download BIOS Update [RYBDWi35.86A]

                 

                Allan.

                • 5. Re: BIOS updating vs. BIOS breaking
                  venik212

                  Thanks, Alan.  This (V.354)  is, in fact, the very BIOS that I am running now.  I have upgraded to it in the hope that it will stop my NUC from dying, but it failed to do so.

                  Right now, after repeated attempts to restore my access to the BIOS I have finally succeeded, and the NUC is working again.  My fingers are like a pretzel from being crossed all the time...

                  • 6. Re: BIOS updating vs. BIOS breaking
                    DrWattsOn

                    I still never got anyone in this forum to address the issue that I believe it is false logic to say "don't upgrade BIOS unless there is a problem"!

                    As I posted on Jan 29 almost 3 weeks ago, and edited (even with coloring) for clarification Feb 1:

                    <q>Additionally I reiterate that not seeing a problem does not mean it isn't lying in wait. My tendency would be to prevent a problem rather than having to fix one, especially if it has significant consequences shortening the computer's lifespan.</q>

                    As I did not say, in waiting for an "honest" response, and as venik212 DID "say it for me": <q>The reason for the rapid fire BIOS release is that there are serious issues with these products--</q> EXACTLY!

                    My question to you, Venik212, is now: did you go directly to v354, and what BIOS did your unit have when you got it? I am assuming that we're talking about the same NUC (NUC5iu7)??

                    I also note to "all", that the questions I asked and even numbered for ease of reference, in my original post, were never addressed especially by "*_intel".

                    To repeat from my 2nd post also on Jan 29, topics

                    <q>

                    1: Platform stability increased by an embedded CPU?

                    2: Platform stability making it easier to nail down and fix BIOS problems?

                    3: Isn't a "prevent defense" more sensible?

                    4: Isn't such a relatively high rate of issuing BIOS Updates indicative of something? Like maybe lack of due diligence by the involved developers?

                    I mean, think of the outcry if they made cars this way ... oh, wait ...

                    </q> 

                    Heck, I was giving an opening of the benefit of considerable doubt, reasons to excuse intel and BIOS mfr's for irresponsible rtm which used to mean RELEASE To Market and now only ever means RUSH to market. "Let's hurry and just get their money by any means" with no fear of retribution that they do deserve.

                    I guess nobody actually reads a thread or notices when no answer really addresses the questions in the Original Post?

                    Ever start a discussion in a room of people, and then they all immediately ignore you while they keep the topic going? Me neither, not in person...

                    Anonymity removes respect.

                    • 7. Re: BIOS updating vs. BIOS breaking
                      N.Scott.Pearson

                      So, the biggest reason why you are not getting a lot of traction is because this is posted in the support forum for Intel's Desktop Board products, not the support forum for the Intel NUC, and most of the regular NUC forum stalkers are not seeing it. Secondly, remember that this is a user-to-user support community. If you truly want Intel support, you should be contacting Intel Customer Support (ICS) directly. There is no guarantee that an ICS person will respond to any particular posting here.

                       

                      I am a former - now retired (old f@rt) - member of the Intel Desktop Board and then Intel NUC product development team. While no longer a paid employee of Intel, I am still bound by nondisclosure agreement from answering your query properly. So, here are my "opinions"...

                       

                      1. Not necessarily. The BIOS certainly isn't burdened with custom initialization code or microcode updates to handle a plethora of possible processors that might go into a particular "socket" - but understand that the processor (and remember too that this is a SOC and there are many chipset components built into it) aren't where most of the stability issues come from. It is the memory, the drives and (worst of all) the USB devices plugged in. There are a lot of (being nice) "poorly implemented" USB devices out there that have to be handled and the average BIOS carries literally hundreds (and hundreds) of workarounds for these devices.
                      2. I think I answered this in #1. No, it doesn't make it any easier. Look at this crazy issue going on with multiple NUCs regarding support for M.2 PCIe SSDs. To complicate things, it was found that some of the SSDs mentioned were not intended for general-purpose usage and came with custom firmware tailored for some third-party IHV's laptops. Who would have guessed. Still, the problem appears to have been introduced after the fact, which indicates that the changes made in a particular BIOS release were not properly/completely regression tested before release.
                      3. I personally believe that the most stable BIOS *is* the latest BIOS. There are folks with Intel 6 Series Desktop Boards who will vehemently disagree with me, however (if no one else). I have never agreed with Intel's adage that you only update if necessary. Of course, I have pooched some systems this way, but (a) this was usually the result of me jumping in and using BIOS releases before they have gone through regression testing and (b) luckily (for me), I am an expert and I can recover them where the average consumer can not.
                      4. It seems that there are a lot of early escapes that need to be reined in. Intel does a *lot* of validation; not just for the NUC as an overall product but also for the drivers for the various pieces of Intel silicon - as well as the silicon itself! - included in each system. Add to that all of the validation that must be done for the non-Intel silicon in every system. Despite this, however, there are many issues that can't be caught before the systems are in end-user hands. Intel simply cannot test every single usage scenario possible and every peripheral device that is out there. This reads like a whiny excuse but, well, there it is. [Aside: Validation is a specialty (discipline?) that is often ignored. I wish more universities would recognize this and do something about educating folks for this field.]

                       

                      Yes, anonymity *can* remove respect; it all depends upon the moral character (or lack thereof) of the individuals involved. I truly believe that our (world-wide) society is going in the wrong direction. Why is it that you only hear this complaint coming from the, um, elderly?

                       

                      ...S

                      • 8. Re: BIOS updating vs. BIOS breaking
                        DrWattsOn

                        @N. Scott Pearson

                        I have been meaning to get back to these forums and reply to you. I was very impressed by your thorough, intelligent, and thoughtful answer, and I thank you for that, and for including your "street creds".

                        Regarding your closing comment: At approaching 72, because we see the timeline better, and know we won't have time to "fix" it and meager hope that anyone lacking the timeline view will heed us.

                        Re: "3": I thought so too until seeing that on the NUC6, even the BIOS 33 was an apparent "rush to market" attempt that FAILED and from the NUC6 posts, Intel replaced 033 with 036 i.e.: they removed 033! So now, I find that companies abandon users ... no, let me rephrase with proper emphasis: PURCHASER$ ... of products only a few months old, yet not only are there no drivers available, there is no access to the product's FULL specifications. Because they're still protected by the corrupt patent/copyright policies today; must not touch! Think HDMI HDCP etc.

                        But again, my gratitude to you for your answers and suggestions and observations.