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 stormwyrm on Wednesday August 14, @06:26AM (5 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by jasassin on Wednesday August 14, @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, @03:17AM (2 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by hendrikboom on Sunday August 18, @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, @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, @10:35PM
Is the keyboard of standard size? I.e., are the keys the usual distance apart, or is it a reduced size?