Louis, yes it would be great if coreboot supported more machines... But you probably understand that it's not a coreboot's fault that the choice isn't wide enough - instead, it's the fault of the modern electronics world which becomes more proprietary-inclined and telemetry (aka spying) -inclined.
But the problem isn't that big: if your old motherboard doesn't support coreboot, there is always an option to sell it and buy another supporting one - for peanuts, because of its age. And, by switching to coreboot, you get a lot: i.e. the many years of free BIOS updates & improvements (+ unlike the proprietary ones which are quickly abandoned by corporations) and cool features not found in proprietary BIOSes - such as this "virtual floppy inside a BIOS" miracle. Also, I'd like to clarify that the coreboot firmware does not pose any risk for the hardware: any "bricking" of hardware, caused by the installation of incorrectly configured coreboot ROM, is temporary - and easily recoverable by replacing it either with a good coreboot ROM; or to the proprietary BIOS ROM in the worst case - but the people rarely have to resort to that, because the coreboot community is really helpful. So many people, even those who aren't really tech literate (but had a strong determination in switching to coreboot, i.e. security considerations) - were able to switch to coreboot with the community's help, and I personally helped many people free of charge. P.S. By the way, if you would like to switch to coreboot opensource BIOS yourself, I'm ready to provide you an exceptional support (free of charge of course!) for any of these 3 motherboards which I own: Lenovo G505S (laptop with A10-5750M CPU, up to 16GB of RAM and working IOMMU), ASUS A88XM-E (desktop with A10-6800K/A10-6700 CPU which is equally good) and AM1I-A (micro desktop with Athlon 5370 but no IOMMU) ^^^ All these coreboot-supported AMD platforms: 1) don't have AMD PSP backdoor (an equivalent of Intel ME backdoor) 2) aren't affected by 20+ Intel-only vulnerabilities like Meltdown (for which the performance crippling patches are required and i.e. even have to disable a hyper threading) 3) are perfectly suitable even for the demanding modern computing (even able to handle the multiple virtual machines simultaneously running, etc.) So, if you'd like yourself a perfect opensource BIOS (and super-secure PC in general) , and not ever be at mercy of corporations for those BIOS updates - this is your chance ;-) ср, 25 янв. 2023 г. в 18:33, Louis Santillan <lpsan...@gmail.com>: > > This would be ideal if coreboot supported more machines > (https://coreboot.org/status/board-status.html). I believe you did some work > some years back to prove out cooreboot+SeaBIOS+FreeDOS. I’m not sure a > typical user or even experienced FreeDOS users would be keen to swapping out > their board’s firmware for a heavily customized solution that could also > brick their hardware. > > On Wed, Jan 25, 2023 at 2:32 AM Ivan Ivanov <qmaster...@gmail.com> wrote: >> >> Friends, the final solution to "UEFI problem" - is switching to the >> opensource coreboot BIOS (although that may involve switching to the >> worthy hardware compatible with coreboot). coreboot's default payload >> - SeaBIOS - is a modern implementation of a classical BIOS, which is >> written in C and is more refined in general. Moreover, you can even >> take a FreeDOS virtual floppy and put it inside your coreboot+SeaBIOS >> ROM's free place of a BIOS chip - and it will be permanently available >> as a boot entry of your system. Efficient and simple, and don't have >> to deal with the problems of UEFI crapware that has been coded for a >> bowl of rice >> >> 2023-01-24 23:38 GMT+03:00, Steve Nickolas <usots...@buric.co>: >> > On Tue, 24 Jan 2023, Bret Johnson wrote: >> > >> >> For purposes we're discussing here, I don't think DOSBox (or any of its >> >> forks, including vDOS) is a viable solution. >> >> >> >> DOSBox really isn't DOS. It's an environment designed to run certain >> >> DOS applications. A lot of stuff is missing in DOSBox that's needed to >> >> make it a "real enough" DOS to be used for development and testing. >> >> E.g., a lot of the internal structures that some DOS "extenders" need to >> >> look at (like certain TSRs and Device Drivers) simply don't exist on >> >> DOSBox. >> >> >> >> A perfect example of this are the "standard" DOS Devices: NUL, CON, >> >> COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$. In DOSBox, the only two >> >> that exist in a form where other programs can "see" them using standard >> >> methods (by scanning through the linked list of Device Driver addresses) >> >> are NUL and CON. >> >> >> >> Things like that can cause lots of problems in certain situations. >> > >> > Though the hardware emulation may be useful, it would be better for such a >> > situation to use that as a base to run an actual DOS on. >> > >> > -uso. >> > >> > >> > _______________________________________________ >> > Freedos-devel mailing list >> > Freedos-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/freedos-devel >> > >> >> >> _______________________________________________ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
