LinusTechTips and being objective.

[manikyath]

Just now, risk said:

Possibly, but what makes you say that though.

because the bios is a VERY basic piece of software, it is quite literally the first checklist a PC performs when starting up, the idea of that piece of software on itself also having a checklist to go trough isnt something that's easy to implement.

 

if it were so easy, people like asus wouldnt have gone with the bios flashback thing, and we wouldnt have dual or even 3-way bioses on some platforms.

[Jito463]

On 3/18/2017 at 10:04 AM, Factory OC said:

AMD Ryzen 7 fanboys. Some people here really can't take in that Ryzen 7 isn't a viable option for gaming at the moment, games need optimizations. 

That's where you're wrong.  Ryzen *is* a viable option, it's just not the fastest option.  That the games need optimization to fully utilize it, doesn't mean it's not viable.

[yathis]

On 3/18/2017 at 7:59 AM, Aphexxis said:

-

 

That is why you need to rely on more then one person and more then one forum and rely on trustworthy benchmarks and trustworthy reviews.

 

If you get upset easily, then you need to learn how to not give a fuck.

[risk]

15 hours ago, manikyath said:

because the bios is a VERY basic piece of software, it is quite literally the first checklist a PC performs when starting up, the idea of that piece of software on itself also having a checklist to go trough isnt something that's easy to implement.

From what I know about x86, whatever is in flash just starts executing from some location in memory as soon as cpu starts running after a reset. I'm pretty sure checksumming and the logic I described can fit into a really small piece of code (<4K for sure), probably even less depending on the checksumming function (I've written simple mbr bootloaders). The interesting question to me is, if it could be done before initializing the cpu caches, but I think that cpu cache initialization, being also a small piece of code would be easy to get right by itself.

[manikyath]

11 minutes ago, risk said:

From what I know about x86, whatever is in flash just starts executing from some location in memory as soon as cpu starts running after a reset. I'm pretty sure checksumming and the logic I described can fit into a really small piece of code (<4K for sure), probably even less depending on the checksumming function (I've written simple mbr bootloaders). The interesting question to me is, if it could be done before initializing the cpu caches, but I think that cpu cache initialization, being also a small piece of code would be easy to get right by itself.

but all of that, gets initiated by the bios, AKA the thing you're trying to checksum

 

the issue is that a modern computer is a very, VERY complex implementation of x86. i have an x86 microcontroller on the shelf, i have no issue with programming that with assembly, but hell i'm staying away from an actual PC

 

in short, that first location of memory the cpu starts to read from, is provided by the bios, which first also has to give an "all systems go" before things actually kick off.

[risk]

3 hours ago, manikyath said:

but all of that, gets initiated by the bios, AKA the thing you're trying to checksum

 

the issue is that a modern computer is a very, VERY complex implementation of x86. i have an x86 microcontroller on the shelf, i have no issue with programming that with assembly, but hell i'm staying away from an actual PC

 

in short, that first location of memory the cpu starts to read from, is provided by the bios, which first also has to give an "all systems go" before things actually kick off.

No, the address to which the flash chip (bios/uefi/coreboot/...) is mapped after reset is part of Intel's spec.

[manikyath]

4 minutes ago, risk said:

No, the address to which the flash chip (bios/uefi/coreboot/...) is mapped after reset is part of Intel's spec.

yes, but you cant quite checksum the stuff you're running off can you?

 

if it would be corrupted, it couldnt run the checksum in the first place.

[risk]

1 hour ago, manikyath said:

if it would be corrupted, it couldnt run the checksum in the first place.

Right, but then again you wouldn't have to update that part of the flash chip (as I mentioned previously). To make a hard drive analogy, imagine having an MBR and 2 partitions. You don't need to update the MBR.

 

The other case is if it were to actually become corrupted, no system is fault proof, but cutting power during updates would be a non issue.

In the case you need to flash the whole chip, it's the same as before -- you need something that speaks SPI (e.g. a raspberry pi) and a testclip to connect it to the motherboard flash chip to not have to solder stuff, and you can flashrom away!

[manikyath]

9 minutes ago, risk said:

you wouldn't have to update that part of the flash chip

but what if the bios update fixes an issue in that part of the bios?

[risk]

18 minutes ago, manikyath said:

but what if the bios update fixes an issue in that part of the bios?

There's very little hardware running at that point, there's few things that can go wrong, and if the code is short, it's easy to review and unlikely to require an update. (same as an MBR that once written usually outlasts the PC using it to boot)

[manikyath]

4 minutes ago, risk said:

There's very little hardware running at that point, there's few things that can go wrong, and if the code is short, it's easy to review and unlikely to require an update. (same as an MBR that once written usually outlasts the PC using it to boot)

technically, everything is running at that point. remember even the cpu voltage is handled by the bios.

 

as for things that can go wrong, how about locking up, accidentially sending too much voltage to the cpu or ram, not to mention how you'd even verify that the bios isnt corrupted, without having an example of what that'd look like. sure you can checksum it, but nothing verifies that the checksum isnt corrupted, and you'd also have to update the checksum library to make sure it can verify that your new bios is actually what it's supposed to be.

 

all of this, pretty much ending in being such a programming black hole merely for the sake of not having hardware there to take care of an issue that is in itself a very, very rare occurance anyways. and if you are so worried about this rare occurance, some mobo manufacturers have gone in and designed hardware to do this in a way that is more reliable and cost effective than trying to make the bios somehow protect itself.

 

ever had a blue screen pointing to a hardware fault? more often than not that's a fault in windows, generating a false positive hardware for a hardware fault. that's a concept you dont want to be in charge of the very core of system initialization.

[risk]

1 hour ago, manikyath said:

technically, everything is running at that point. remember even the cpu voltage is handled by the bios.

 

as for things that can go wrong, how about locking up, accidentially sending too much voltage to the cpu or ram, not to mention how you'd even verify that the bios isnt corrupted, without having an example of what that'd look like. sure you can checksum it, but nothing verifies that the checksum isnt corrupted, and you'd also have to update the checksum library to make sure it can verify that your new bios is actually what it's supposed to be.

 

all of this, pretty much ending in being such a programming black hole merely for the sake of not having hardware there to take care of an issue that is in itself a very, very rare occurance anyways. and if you are so worried about this rare occurance, some mobo manufacturers have gone in and designed hardware to do this in a way that is more reliable and cost effective than trying to make the bios somehow protect itself.

 

ever had a blue screen pointing to a hardware fault? more often than not that's a fault in windows, generating a false positive hardware for a hardware fault. that's a concept you dont want to be in charge of the very core of system initialization.

I don't think I can discuss this with you at this point in time, here's a useful article that should clarify some misconceptions you might have: http://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par/232300699 

[manikyath]

4 minutes ago, risk said:

I don't think I can discuss this with you at this point in time, here's a useful article that should clarify some misconceptions you might have: http://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par/232300699 

here's something for you to consider then:

 

if this is all so easy to implement, then why hasnt a single mobo manufacturer done it that way?

[ThioJoe]

If you want objectivity, read a spec sheet.

[risk]

48 minutes ago, manikyath said:

if this is all so easy to implement, then why hasnt a single mobo manufacturer done it that way?

I'd like to know too, I can guess that somewhere a line was drawn and better RGB stuff was above the line, and this was below.

[manikyath]

Just now, risk said:

I'd like to know too, I can guess that somewhere a line was drawn and better RGB stuff was above the line, and this was below.

the line is quite simple: a hardware solution costs more in components, but earns back the difference on reliability and programmer work hours.