BIOS ROM 2.5MB but chip size 4MB?

If you got it from Lenovo, OK. If you picked it up somewhere else, not OK.

 

It may be compressed or it may be skipping some areas, or both.
I wouldn't worry.

 

That's awesome. Stick a proper bootloader in it, like reFind, CloverEFI, Grub2, or Syslinux. Even cooler, go with one that incorporates a mini-Linux kernel and kexec like kboot, petitboot, or (I think it does?) Uboot. If you go the kernel route you can probably remove unnecessary oprom modules from the flash image because all modern operating systems basically ignore BIOS info anyway. You could also easily do things like wifi net-booting and/or a remote telnet interface to your boot sequence...

Edit: Oh yeah! I forgot about Kolibri and Menuet! Whole OSs written entirely in assembly and designed to fit on and boot from a floppy. Google for those things.

tldr: you can do a lot with 1.5mbs of free flash

 

Sign on the dotted line that you wont hold mikeserv (or me) responsible if something fuc*s up lol.

 

Long winded


Note: If by some miracle you actually read through all this and still find yourself awake enough to investigate the meaning of the "references" herein, please find them in a document at "gdriv dot es slash hopeful_dumps" entitled "References." Please also find any other document directly in that folder where I allude to "hopeful_dumps." There's nothing there but text dumps and a file linking to other noteworthy forum posts. Honestly. Cross my heart. But I was unsure of how the link detection worked here after being told several times I couldn't post links cause I'm probably a dirty spammer.

Note2: Oh. I lied. There's also a picture of a rom chip. Fu*k.

Note3: Yeah. Lied again. So there are also some dumps in there taken from the UEFI shell like "dmpstore > nvram", "pci > pci", and "dmem > dmem". These apparently innocuous commands have for some reason resulted in some kind of evil byte-code binary files. Warned you.

Ok, point taken. Easier said than done, right? But seriously, let's at least talk about it. We should be able to do this stuff, especially now that UEFI size requirements have ballooned our integrated flash chips. It's the perfect time to do this. Consider:

1) The move from BIOS to UEFI and Assembly to C has, as noted, resulted in a dramatic expansion in firmware's available flashable medium.

2) Manufacturers, still as tight-lipped as ever about their specific implementations, have nevertheless adjusted to the more comfortable flash limits by producing looser and sloppier code that practically begs to be chipped down and stripped to nothing.

3) In fact, in most cases it seems most necessary hardware initialization functions are still performed by those familiar (and tiny!) legacy BIOS programs packaged in UEFI as Compatibility Support Modules.

4) Much of the rest of the code actually on the flash chip is designed to support UEFI's pre-OS emvironments and C extensibility functions. It promises to offer things like true type-0 hypervisors and secure network namespaces and a reliable, callable framework layer between the hardware and the OS.

5) The problem is, it doesn't do those things yet. At least not well. When correctly implemented (as it so rarely is) the best it's really offered us so far is a completely useless higher resolution gui with fancy mouse-support to interface with the same basic BIOS functions we've happily ignored for years.

6) While BIOS's resident functions used to matter, and OSs used to depend on it for interfacing IRQs and similar, pretty much since the advent of Plug-And-Play (about 20 years ago) the OS has been directly interfacing hardware.

7) Modern x86 OSs mostly only rely on firmware to start and then take it from there. Yes, that's oversimplifying things, I know, but they really basically do a rePOST every boot. They remap oproms (often with their own firmware images loaded from disk into memory), probe PCI, clock CPUs, spin disks up and down, control fan rpms, even patch cpu microcode... When faced with a conflict between their own device discovery and information supplied them by firmware they nearly always discard firmware's information in favor of their own. Firmware memory space has become a hindrance and most firmware interface code written into operating systems is designed to circumvent, ignore or patch it.

8) Sure, sure, UEFI can change all of that. And maybe it will. But not today, and we don't much need it now anyway. We already have OSs that can do it and that have been doing it for 20 years.

9) What it does give us now, though, is room to play. Enough flash space to migrate customized core OS kernels onto board flash for nearly instantly available execution environments. And yes, probably the same can be had on the high-road with UEFI and Secureboot and the like, but not in an openly understood and natively hackable way. It's UEFI or the highway, it seems, so I say we hit the road.

10) Look at all of the community developments and progress made in the Android community on ARM in just the past few years. That's hack-heaven. Some might justifiably argue that it has less to do with open firmware space than it does with Android's open Linux core, but iOS is based on BSD and while it's also seen it's share its share of hacks they don't come close to the depth and breadth of Android community customization. And iOS is older!

Just what the hell am I talking about anyway?

From what I can tell it seems that most x86 community firmware modifcation efforts are centered around either injecting patched machine identity codes for software verification purposes or upgrading firmware driver modules that manufacturers probably should have provided in the first place. Both of these are noble efforts in that they serve to expand on the capabilities and lengthen the practical lifespan of hardware - hardware often prematurely obsoleted by its own manufacturer's limited support.

The problem with these efforts is that they're too thinly spread and narrowly focused to have a real effect. These initiatives exploit possibly game-changing vulnerabilities only to alter a byte or two and drop out. Ultimately that kind of strategy is self-defeating in that it empowers the producer at the expense of the consumer. Faulty, barely tested firmware drivers are replaced with newer, less-tested iterations of the same with dubious provenance because the official manufacturer ceased providing firmware updates some six or so months after their first version. And I think it's safe to assume that the widespread community SLIC table modifications probably had a signifcant impact on Microsoft's zeal for UEFI's Secureboot despite its well-publicized issues.

Of course, I fully understand this, too. Firmware is f**king hard, man. I mean, that's why I'm talking about hacking at UEFI rather than replacing it with coreboot or some other more elgant solution. It's really f**king hard. And the margin for error is nil. f**k it up the first time and you'd better hope your solder skills are up to snuff, because the chip that's responsible for initializing your $1000 computer system just bit the dust. The tech is never openly documented and is initially implemented onboard only days or weeks after module release by the same people that drop update support for it six months later for reasons they would rather not say. Add to all of that the complexity of trillions of transistors and the relative comfort of using a system that does currently work despite its faults and it's no wonder we don't hear more tales of x86 embedded derring-do.

But I think that's changing. UEFI is modular after all. It's core implementations are also standardized to a certain extent, at least inasmuch as the many available manufacturer variations are likely to be little more than superficial modifications to Aptio or Pheonix made with the same tools we (ahem!) have also obtained.

Look no farther than MDL for practical examples. Self-protecting flash routines are circumvented time and again. SLIC goes around and around again on a Microsoft release cycle. Flash is borked and then unborked on a regular basis.

MMTool has been exploited ( reference #1 ) to provide a nearly automatic firmware driver discovery and update interface. The developer and the reviewer both suggest removing unnecessary modules as needed. (many similar other step-by-step instruction sets can be found in the same forum)

The linux kernel has incorporated native UEFI loader executable code since (around?) version 3.3 and the guys at EFI linux kernel devel seem to be close to implementing kexec reboot support. This means the linux kernel can be loaded directly by UEFI without needing any intermediary bootloader, can already nearly instantly load any other OS kernel via kexec by mapping it into memory and mapping itself out in legacy BIOS mode, and will soon be able to reliably do so in UEFI-aware mode as well.

Linux also recently mainlined .lz4 support, which brings superb multicore-capable on-the-fly compression to speed ratios. And because the kernel is also modular and can be built with as many or as few drivers as is necessary, compiled specifically for a target achitecture with libraries designed for minimal binary sizes like uclibc, it is well within the realm of possibility to produce a bootable kernel with drivers enough to find the disk you want in under 1mb. Add to that Linux's capability of chainloading init ram disks to add driver suport as disks are found and you have a fully on-disk configurable bootloader as OS. And if you want a different OS, kexec it!

This becomes especially significant in light of the recent Hackintosh community accomplishments. Probably they've got it harder because OSX is unique in that it doesn't simply discard firmware data when it doesn't deliver as expected, but instead refuses to boot, similar in a way to what Microsoft hopes to achieve with Secureboot, I guess. Anyway, in only the past few months, happening all over apparently, but much of the work occurring here on MDL ( reference #2 ), xpamamadeus and others successfully modified a gigabyte UEFI to boot Mac natively with custom DSDTs, stripped and/or modified DXE drivers, and a custom, fully independent bootloader called ozmosis loaded from BIOS flash.

In my biased opinion, xpam's efforts might have been better devoted to injecting a linux kernel based loader and then instructing it to populate firmware memory space with whatever information he desired, but that does not detract from his achievement. Moreover, this confirms my hope that UEFI is hackable and that possibilities like those I mentioned in the first post can be realized. And soon.

Here's a look an MMTool report generated from a freshly downloaded rom for my Asus laptop board:

Code:

+-----------------------------------------------------------------------------+
| Firmware Image Information                                                  |
+-----------------------------------------------------------------------------+
| Image Size : 280000                                                         |
+------+-------------------------------+--------------+-----------+-----------+
|  FV  |            FV TYPE            |   Location   |   Length  |    FFSs   |
+------+-------------------------------+--------------+-----------+-----------+
|  00  |          FFS FV               |   00090000   |  010000   |    001    |
|  01  |          FFS FV               |   000B0000   |  140000   |    004    |
|  02  |          Nested FV            |   00000000   |  3D7000   |    135    |
|  03  |          Boot Block FV        |   001F0000   |  090000   |    025    |
+------+-------------------------------+--------------+-----------+-----------+

...

+-----------------------------------------------------------------------------+
| Total Bytes Free : 0B14D0 ( 709 KB)   Total Bytes Used : 1CEB30 (1850 KB)   |
+-----------------------------------------------------------------------------+

(You can find the whole file and others at hopeful_dumps).

The 2.5mb image total size looks familiar, huh? Seems these firmwares begin reading at an offset that is likely because they are sharing the flash with the Embedded Controller. The flashrom crew have an unsavory opinion of this arrangement, but it explains the 2.5mb image size v the 4mb chip size noted by OP and for which I've found reports for Sony and HP models. (Note: per flashrom, don't f**k with ec's.)

Nevertheless, without any effort on my part Asus has granted me 700kb of free space in their ROM image. Yes, yes, it's not contiguous, and no, it's not even all on the same partition, but surely there are better minds than mine out there that can puzzle out such trivial matters, right?

Anyway, I also have a Gigabyte GA-970A-D3 with DualBios. In the Hackintosh thread mentioned above, Xpamamadeus notes how he was easily able to recover from corrupt firmware flashes thanks to the automatic backup and restoration features of his DualBios equipped board. That emboldens me somewhat.

Findings are in line with the laptop board. ~650kb free noncontiguous flash space of possible 4mb. Full dumps at hopeful_dumps.

Code:

+-----------------------------------------------------------------------------+
| Firmware Image Information                                                  |
+-----------------------------------------------------------------------------+
| Image Size : 400000                                                         |
+------+-------------------------------+--------------+-----------+-----------+
|  FV  |            FV TYPE            |   Location   |   Length  |    FFSs   |
+------+-------------------------------+--------------+-----------+-----------+
|  00  |          Non-FFS FV           |   00030000   |  020000   |    001    |
|  01  |          Non-FFS FV           |   00070000   |  2B0000   |    128    |
|  02  |          Non-FFS FV           |   00320000   |  020000   |    004    |
|  03  |          Boot Block FV        |   00340000   |  0C0000   |    027    |
+------+-------------------------------+--------------+-----------+-----------+

...

+---+---------------+------------------------------------+--------+------+----+
| Bytes Free       : 022760 (137 KB)    Bytes Used       : 09D8A0 (630 KB)    |
+-----------------------------------------------------------------------------+
| Total Bytes Free : 0A1E00 ( 647 KB)   Total Bytes Used : 35E200 (3448 KB)   |
+-----------------------------------------------------------------------------+

I apparently also have a BioStar A780L3G with no processor that I've just pulled out of the closet. It is sporting a slotted 1mb EN25F80. ( reference #3 )

Pic: hopeful_dumps

This is an interesting development and I'm very curious now as to how this could be experimented with. Is it possible that my Asus U56E laptop or my Gigabyte GA-970A-D3 could make use of this? Research is necessary. Yes, and there's a partially disassembled Core2Duo box in one cabinet and a mostly intact Athlon x64(2 or something?) HP box on the top shelf, which should be in working order but which bear little chance of sporting UEFI firmwares. Still, if I can help with a test of something interesting I likely will.

Disclaimer:

I am mostly retarded and yet somehow also manage to be stuck-up. Most of the concrete information provided above I have gathered sometime in the past 24 hours or so since first crossing jamesm80's question and relating it my own (found: reference #4). If not gathered in that time it might be simply made up for all you know, but is more likely half-remembered from a look into coreboot some months ago and/or otherwise gleaned from my proud 30 years history of fuc*ing-up electronics.

-Mike