SoylentNews is people
SoylentNews
Arthur T Knackerbracket has processed the following story:
In separate statements, ASUS and MSI announced their plans to deliver the new microcode for 13th and 14th Gen Raptor Lake Core family of CPUs over the course of August.
The updated CPU microcode, which should be finalized in the coming days, is supposed to stop Intel's wobbly desktop microprocessors from crashing at normal clock speeds (an "instability" as the x86 giant puts it) to frying themselves and causing permanent damage if not complete failure.
Apparently, the original microcode for Raptor Lake processors applied too much voltage to chips. While increasing voltage can make it possible to hit higher clock speeds with ironclad stability, too much voltage can be dangerous and degrade the silicon.
Although microcode updates are developed by Intel, they have to be distributed via motherboard BIOSes developed by individual motherboard vendors, including DIY brands like ASUS and MSI, and also OEMs. When it comes to microcode patches, Intel (and its rival AMD) can't guarantee when users will receive it or if all users will even get it at all, since it is up to individual motherboard makers to issue new BIOS versions.
That's not ideal for both Chipzilla and owners of Raptor Lake CPUs, as the longer it takes for the microcode to disseminate, the more opportunities there are for more chips to fail, providing more fuel for potential class action lawsuits.
However, at least ASUS and MSI seem to be working fast on updating their motherboards, with both saying that they'll start distributing BIOSes with the new microcode next week. Intel said the microcode itself wouldn't be done until the middle of the month.
[...] "The two tech companies have yet to update any 600 series boards, however. For its part, Gigabyte says it expects all of its motherboards to get updated by the second week of September at the latest, a representative toldThe Register.
(Score: 3, Interesting) by Rosco P. Coltrane on Tuesday August 13 2024, @03:21PM (9 children)
but I've finally decided that my next laptop is going to be a MNT Reform [mntre.com], and the thing that pushed me over the edge is Intel [arstechnica.com]'s and AMD [pcgamer.com]'s latest flaws.
I'm not delusional: I realize springing for a MNT Reform requires being a certain kind of customer and it's anything but mainstream. But even weird me has been only 90% near the edge for months, because even I can see an ARM laptop is going to require some customizing work and a lot of compromises.
But what finally pushed me over the edge is entirely Intel's and AMD's doing. Especially Intel's: they've truly become the Boeing of the CPU space.
(Score: 2) by vux984 on Tuesday August 13 2024, @04:38PM (1 child)
I guess that's one way to play it. Select a bleeding edge crowd sourced product that's going to have all kinds of flaws out of the gate so you won't notice if some new one is discovered in a couple years. Don't get me wrong, it sounds like a fun trip if you enjoy playing with that type of hardware, but it smacks of buying a kit car to build yourself because VW and Ford issued recalls. kit cars are fine, and lots of fun... but its a pretty bold assumption that the kit car is going to be less flawed.
(Score: 2) by Rosco P. Coltrane on Tuesday August 13 2024, @04:52PM
I have no doubt that the ARM platform is just as broken and as vulnerable as Intel or AMD stuff is. But it certainly present a minuscule attack surface area compared to them: nobody makes ARM Linux malware.
But like I said, it was a minor factor in my decision to go with that architecture. I've been wanting to get one for months, but the price is kind of ouch. However, I need a new laptop, I can't wait and the current crop of Intel and AMD CPUs on offer have gotten much less attractive as of late.
So ARM it is.
(Score: 3, Interesting) by stormwyrm on Wednesday August 14 2024, @06:26AM (5 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by jasassin on Wednesday August 14 2024, @06:43AM (3 children)
So many questions here... what OS do you run on it? What is its primary function? Do you have to compile your own software often, and what's the success to failure ratio if you do attempt to compile a program? What do you think of RiscV in general? Is it a pipe dream or is it plausible? What was your biggest problem/deal breaker with RiscV?
I have never owned any RiscV systems so I am ignorant.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 3, Informative) by stormwyrm on Thursday August 15 2024, @03:17AM (2 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by hendrikboom on Sunday August 18 2024, @01:57AM (1 child)
I looked at the list of Devuan images on ARM system.
There are lots of ARM systems, and the all seem to need their own specific Devuan system.
It looks like distros have to support a lot of installers for machine with very similar instruction sets.
With traditional x86 PCs, a very few images seem to do for most of them, because there is very little difference in the way they boot up (mostly just 'legacy' and/or UEFI).
Is the boot-up landscape on RISC/v relatively sparse, or does every RISC/V board and computer need its own individual boot-up procedure?
(Score: 3, Informative) by stormwyrm on Sunday August 18 2024, @06:01AM
Mostly the differences between the specific versions geared towards the various SBCs have to do with the different Devicetrees that need to be loaded on bootup. These devicetrees are files that describe what specific hardware is present on the board and what settings to use for them so that the bootloader and the kernel can configure and use them properly. They're not used on PCs because there are various standard auto-configuration protocols like ACPI that accomplish the same thing. Before devicetrees were introduced, a distro maintainer needed to patch the bootloader and kernel specifically to hardcode the hardware configuration of the target SBC. Today, they can just set configuration switches for them to load the appropriate devicetree for the hardware meant to be used. For the average user it amounts to the same thing (downloading a version specific to the SBC you want to use) but the real differences between the images for different SBCs having the same CPU architecture family are in general trivial. This would go away if there were a standard where the bootloader can obtain the devicetree for a board (e.g. from a standard interface to an EEPROM), but there is no such standard at this time.
I've just begun looking into the way the boot-up procedure on RISC-V systems is supposed to work and it seems that RISC-V International has published standards for this. They have something called the Supervisor Binary Interface (SBI) that is basically the analog of a PC's BIOS that every non-trivial RISC-V system (i.e. one that is intended to be more than a small microcontroller) is supposed to have and like the PC BIOS it does well-defined things on boot. I believe ARM may have something similar but I haven't yet been able to look as closely into that yet. There is a very widely-used bootloader called U-boot for both ARM and RISC-V that is basically the de facto standard for booting Linux on SBCs.
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by hendrikboom on Thursday September 05 2024, @10:35PM
Is the keyboard of standard size? I.e., are the keys the usual distance apart, or is it a reduced size?
(Score: 2) by hendrikboom on Wednesday August 14 2024, @04:39PM
Of course there's also the Pinebook and the Pinebook pro. Both are ARM machines, the pro being designed after they discovered what was problematic on the non-pro version.