Hello Ged, > > I guess this should do for my daily wallpaper... > > Damn, that was interesting. Thank you. > thanks for the compliment, not sure to what extent this was deserved :->
> Any time you feel like expanding on it please feel free to do so - not > forgetting references, references, references, and references. > Uhh... that last message was pretty much my compendium of known dead ends, laced with fading memories of my occasional ventures in this direction. Expanding on those tangential "hinted veiled references" would get me writing a "user's guide to the world at large". None of that is specific to DOS, and DOS seems to be fading away from BIOS/UEFI flashing / modding / survival. I myself am "forever a script kid" at best - and in my optics, there's not much you can do in the way of "BIOS hacking" on your own, anymore. Just to add a few more references that are halfway relevant: I've just found this forum thread where someone has published his build of Flashrom 1.4 = relatively fresh: https://winraid.level1techs.com/t/tool-flashrom-v1-2-dos/36544/32 No clue if this is safe / free of malware. Approach at your own risk. I could follow-up with some examples of the Flashrom usage, cmdline arguments and the like, a bit of word salad about its capabilities and "problems solved", a tangential note about LPT/SPI adaptor hardware for out-of-band flashing, but I doubt this is relevant here... The AMI afuwin/afuefi tools are available for download from AMI: https://www.ami.com/bios-uefi-utilities/ Note that APTIO seems to be a nickname for the modern strains of AMI UEFI "FIRMWARE" (oldspeak: BIOS). Regarding the UEFI shell, some binaries for installation on a USB stick can be found here: https://github.com/pbatard/UEFI-Shell/releases The accompanying readme: https://github.com/pbatard/UEFI-Shell Apparently, you can just download an ISO and copy it to a USB stick using Rufus. Or you can go the harder way: format the USB stick with FAT32, create the directory that UEFI "BIOS" is looking for (/efi/boot), and copy+rename the bare 64b EFI Shell binary to the name expected as a "boot loader" (/efi/boot/BOOTX64.efi). https://kcm.trellix.com/corporate/index?page=content&id=KB90801 Once the EFI shell starts, you can use its command line to do "various stuff". Perhaps the only non-trivial thing is, how do you access the directory tree on your USB stick, or any other disk with a supported filesystem. That first step appears to be: shell> fs0: (followed by the Enter key). You should end up in the root of the first file system found. >From there, you can do "cd" into subdirectories, you can run further executable binaries in the .EFI format etc. Such as, you can run the original "afuefi" flashing tool by AMI. If you really don't know what to try next, try the "help" command. The command set for basic file and directory manipulation seem to be a mix of familiar DOS and UNIX style commands. I recall using the drvcfg + drvdiag commands to tweak something... I don't recall the context anymore. Possibly had something to do with PXE booting. There's an open-source tool that I've used with varying success to inspect the internals of UEFI firmware images (taken by Flashrom). https://github.com/LongSoft/UEFITool On that Github page, if you click "Releases" on the right, you get offered compiled binaries in various flavours, including for Windows if you are so inclined. Not that I've achieved anything productive with this tool, but if you're looking for stuff to poke and study, and you have some modern UEFI-based PC hardware in your paws, this UEFITool will definitely give you some food for thought. If you try some modding, you may as well end up with a bricked motherboard... "dual BIOS" models may be handy. Or a way to restore the ROM image from backup "out of band" (e.g. via SPI from a second machine). > Can you say anything specifically about BIOS in RAM? > Not really. Never quite investigated that. Yes the BIOS starts from ROM, then possibly unpacks or copies stuff into RAM, you will probably find some of its "areas occupied" in the E820 memory map... (or it may be lurking in areas *not mentioned* in that public memory map?) I don't know. Perhaps the only thing that has remained of the traditional x86 start-up sequence is the initial hardcoded jump vector, which must point into a small window where the BIOS ROM is mapped by the chipset hardware on cold start-up. From there, the BIOS can do what it wants. Copy stuff to RAM, change CPU addressing modes (real/unreal/protected/whatever)... the modern BIOS/UEFI flavours probably do their "thing behind the scenes" in 32 or 64 bit mode, of which DOS is kept completely oblivious... (if suported by a CSM, which often it no longer is) Maybe check the answers of user JdeBP in these two topics: https://superuser.com/questions/336021/is-bios-read-from-the-bios-chip -or-copied-into-ram-on-startup https://superuser.com/questions/695690/who-loads-the-bios-in-ram-durin g-computer-bootstrap ...not a comprehensive answer, but I haven't found any better, in this compact format. There's probably a lot to learn about the x86 memory protection / paging mechanism, the MTRR's and whatnot... Frank _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
