From: noemail@basdxcqvbe.com   
      
   On Tue, 13 Jul 2021 13:55:40 GMT   
   scott@slp53.sl.home (Scott Lurndal) wrote:   
      
   > Rod Pemberton  writes:   
   > >On Mon, 12 Jul 2021 17:09:08 GMT   
   > >scott@slp53.sl.home (Scott Lurndal) wrote:   
   > >> Rod Pemberton  writes:   
   > >> >On Sat, 10 Jul 2021 16:07:57 GMT   
   > >> >scott@slp53.sl.home (Scott Lurndal) wrote:   
      
   > >> >> Updating the firmware image is very complex, and the firmware   
   > >> >> contains several security-related blobs (microcode updates,   
   > >> >> SMM mode code, etc) that one must husband carefully.   
   > >> >   
   > >> >It's only "complicated" if you're using the same device to update   
   > >> >it's own firmware.  If the chip is programmed off-board, it's not   
   > >> >difficult.   
   > >>   
   > >> When was the last time you created a firmware images for a mondern   
   > >> processor?   
   > >   
   > >I never did.  I worked for an electronics manufacturer which did   
   > >their own embedded ROMs in house.  That was some decades ago.  They   
   > >were E2PROMs, and not for PCs.   
   > >   
   > >> I'm not talking about the process to update the firmware storage   
   > >> device, I'm talking about the process to create and compile   
   > >> the firmware.   
   > >>   
   > >> We have a team of a dozen engineers working on ours.   
   > >   
   > >Ok.  (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )   
   >   
   > Ah, but the "application visible" portion of the BIOS (e.g. the   
   > interrupts that Paul is so fond of) is a very, very small part   
   > of the BIOS.   
   >   
   > The vast majority of it is processor-specific code to initailize   
   > the hardware (memory controllers, mainboard i2c components,   
   > PCI/PCIe controllers (link training, PCI discovery),   
   > serializer/deserializers, processor microcode loading, and a hundred   
   > other things that most people aren't aware of.   
   >   
      
   ...   
      
   > >> FWIW, there are no systems anymore where the "chip" can be removed   
   > >> from the mainboard to be programmed by an external PROM programmer.   
   > >   
   > >Well, this x86 motherboard, circa 2009, has dual-BIOS stored in two   
   > >small 8-pin surface mount DIPs.  I.e., snip them off, remove old   
   > >pins, clean up the board, replace with newly programmed chips, and   
   > >solder on. Just about anyone can do this at home with no special   
   > >tools, but they may need some experience.   
   >   
   > But why?  Today you have SPI-based flash devices that can   
   > be programmed dynamically, if you know how.   
      
   The point was there is always a way.   
      
   > >As for what is required to build a new firmware image, I'm assuming   
   > >that Paul will start with some open source project like Coreboot   
   > >(formerly LinuxBIOS) with SeaBIOS.  Some motherboard manufacturers "   
   > >... offer coreboot alongside their standard BIOS ..." according to   
   > >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among   
   > >others.  In other words, if Paul acquires the correct hardware, the   
   > >work of programming both the hardware and non-hardware portions of   
   > >the BIOS or UEFI are done for him.   
   >   
   > Those have very limited hardware support.  Very limited.   
      
   So?  Today, we have Amazon and Alibaba, where you can get just about   
   anything, no matter how obscure or specific or obsolete, especially   
   electronics.  Yes?  There was a point in the past where you had to   
   settle for what a local store carried, or what some regional   
   electronics supplier had in stock, or pay a fortune to a large national   
   supplier, but not anymore.   
      
   > >So, all he needs after that is some   
   > >programmable chips a chip (re)programmer, etc.  I'm sure the people   
   > >who work with these projects regularly have provided instructions on   
   > >what to do, where to buy, etc.   
   > >   
   >   
   > We use tianocore as the basis for our UEFI subsystem.  However,   
   > that's a very small part of the firmware[*].   The TC UEFI code is,   
   > for the most part, hardware independent.   The hardware-dependent   
   > parts of the firmware are the responsiblity of the builder of the   
   > hardware.  And for that you need deep specs for all the hardware,   
   > understanding of things like serial-presence-detect memory devices,   
   > I2c/I3c voltage and temperature sensors, mainboard PLDs, etc.   
   >   
   > [*] Most of our customers prefer uboot over uefi, both of which are   
   >     components added to the firwmare that rely on mainboard specific   
   >     code in the firmware.   
   >   
   > Not to mention the SMM code - a significant challenge to develop   
   > without access to proprietary specifications from the mainboard and   
   > processor vendors.   
      
   Both tianocore and that some motherboard manufacturers offer a   
   coreboot solution which works for their hardware was mentioned above.   
      
      
   --   
   The Chinese have such difficulty with English ...  The word is not   
   "reunification" but "revenge".   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)