[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linuxbios
Subject:    [coreboot] Re: A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot
From:       zir_blazer () hotmail ! com
Date:       2020-01-17 21:39:28
Message-ID: 157929716855.18.7776235090805051895 () 9548bf9ee149
[Download RAW message or body]

Mike Banon wrote:


> It would've been helpful if your article had your e-mail in the end of
> it or a reply form - I've stumbled upon your article some time ago,
> but didn't find a quick way to share my feedback and got distracted by
> something else, maybe the others did too...

I didn't include an E-Mail because I posted this mostly in forums where other \
registered users could already reply in public, instead of doing so privately.


> 1) Thanks for describing CH341A, as it is a simple, reliable and
> affordable flashrom-supported SPI programmer. However, there's a
> problem that some CH341A give 5V voltage instead of 3.3V - although,
> as the time passes, these incorrect CH341A models will disappear, it
> could be worth mentioning this problem so that your reader will test
> the voltage of his CH341A before using it. By the way, even the
> "incorrect ones" may be fixed by a small hardware mod.

The focus was pretty much on describing the convenience of a socketed SPI Flash \
EEPROM and how these could be easily reflashed with an external reprogrammer, then \
put the CH341A as an example of how cheap and accessible those tools actually are \
(FAR cheaper than having to purchase a cheap Processor just to boot, and without \
needing fancy ECs/BMCs potentially increasing the Motherboard BoM). It was not about \
describing the reprogrammer itself. Also, as far that I know there are 1.8V SPI Flash \
EEPROMs, which requires support from the reprogrammer, too. I don't know whenever the \
3.3V versions are the mainstream ones or if there are major uses for the 1.8V and 5V \
versions. I suppose that anyone that is actually going to use a reprogrammer will do \
its homework by reading any instructions and compatibility list anyways as to not \
screw up.


> 2) I didn't like your opinion of SeaBIOS, that it's just "mostly used
> to support legacy OSes and PCIe Cards with Option ROMs that have only
> a BIOS compatible Device Firmware."

Remember that I'm an almost Windows-only user. I can't see any reason why a person \
with a blank drive would go for BIOS-MBR instead of UEFI-GPT in a new Windows \
install, unless they already have a MBR formatted drive that they want to reuse \
without repartitioning. Also, since Windows ONLY works in these two modes, it means \
that if you want to use SeaBIOS because you don't like TianoCore, you're limited to \
MBR and its 2 TB boot disk limitation. This would work fine right now because with a \
rather mainstream build being a 512 GiB/1 TiB SSD plus a big HD, you could partition \
the SSD with MBR and install Windows in BIOS mode, whereas the big HD could be \
formatted as GPT and Windows could still use it for storage with no issues. In 2-3 \
years or so when you average SSD size is 2 TiB, SeaBIOS for bare metal Windows \
wouldn't cut it any longer.


> 3) It a bit puzzles me why you didn't mention any interesting
> floppy-based OS like Kolibri in the "floppy part". Windows 3.1 may
> seem interesting, however there wouldn't be any updates or software
> for it, it's stuck at whatever level has been reached during its'
> lifetime, while a lot of the other floppy OS projects - i.e. some of
> those I'm offering with csb_patcher.sh script (KolibriOS, FreeDOS,
> MichalOS, Snowdrop, Fiwix, Memtest, Tatos, Plop, FloppyBird) - are
> still being developed. At least you've mentioned a FreeDOS, but there
> are many interesting floppy projects - including those with a
> minimalistic Linux environment, and PicoBSD - which haven't been
> mentioned even in brief. Perhaps that's because your Tianocore payload
> does not support the floppies, so you didn't have a chance to explore
> this wonderful world personally. I really feel this part is a bit
> short and could be really expanded. In example, if KolibriOS supports
> your Ethernet controller, you could access the Internet right from
> your BIOS and IRCC chat with your friends.

Oh, you just made me remember the sea of hobby OSes that you could find at OSDev and \
FASM (Flat Assembler) Forums. Still, your average Hardware enthusiast may not even \
care about those if they don't do something to enchant its Windows experience, or \
solve a particular issue. The reason why I mentioned Windows 3.1 was because there \
was a recent article about it in a non-extremely-niche website, whereas I don't \
recall the last time I heared anything about the others if you're not looking \
specifically for them in places that cater to hobbyst OS developers (I did mentioned \
Memtest, though). Embedding FreeDOS serves a purpose: It may allow you to perform a \
Software flash of either your Motherboard Firmware or a PCI Card without needing to \
make a booteable USB Flash Drive. I suppose that you could download a binary, copy it \
to a local disk ESP (EFI System Partition), then use embedded FreeDOS to read the \
file there to flash it, or do the same with a data-only USB Flash Drive. It could be \
redundant if you can do the same from the EFI Shell, though, which in some \
Motherboards is actually embedded.


> 4) By attempting to stay further from "anti-spy crowd", it seems like
> the information security advantage of coreboot has been almost skipped
> - i.e. Ctrl+F by Computrace gives no results. Maybe it's not a big
> loss, considering this security part is well covered at the other
> articles - however, it may be worth considering expanding this part if
> you'd like your article to be truly wholesome.

How many people you have already read that focuses only on the security aspects of \
Coreboot? Pretty much all of them. I wanted to do something different, which is why \
I'm specifically intersecting how an open source Firmware could fix all the BIOS \
modding shortcomings, which is what enthusiasts have to do if they are somehow \
limited by their propietary Firmwares. For those that cares about the security topic, \
they already have plenty, if not an infinite amount of material to read. Actually, if \
I were to expand this, I would add even more examples of how a bad Firmware hurts \
general functionality (I just remembered the epidemy of bricked Samsung Notebooks due \
to an overfilled NVRAM some years ago, how guys involved in audio production tries to \
reduce DPC Latency as low as technically possible, etc). Yet, I DID tangentially \
touched the security topic since you have the WPBT ACPI Table, which is a potential \
entry point for persistent malware for anyone running Windows 8+ and is also used for \
tracking Software (I know nothing about Computrace, maybe it uses it).


> 5) Try to shrink your "wall of text" while preserving as much
> information as possible. Aside from the issues above, your article
> really seems great and well-written, but it takes some hard work to
> get through it instead of TLDR hops between the interesting parts. If
> you could succeed in compressing, will be much easier to read.

I don't think that I can shrink the text and still make it accessible enough for \
people that have near-zero knowledge. I introduce you to a situation, tell you why it \
is a problem, then how it is currently solved usually via BIOS modding, and how an \
open source Firmware would be a superior option. \
_______________________________________________ coreboot mailing list -- \
coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org


[prev in list] [next in list] [prev in thread] [next in thread]