@ramalhais Thank you for your hint's - I way able to spot in the "FlashDriverSmm" used Flash I2C devices & vendors (
@Danlopez1222) was searching it too.
Like e.g.:
Fudan FM25W
ATMEL 26DF041
etc...
(and yes, it makes perfect sense there are couple of IC's to choose from, even manufacturers want to stay flexible and have a way to react to shortages of particular brands)
So the activator chip runs at 3.3V. [...]
Here are the Pulseview session files for the Analyzer
The next issue is that my hardware flasher won't read anything from the chips when set to 24xxx I2C EEPROM. It detects that an i2C chip exists there, but it just reads empty files. Is there a substantial difference between the 24xxx series of EEPROMS and the 34xxx series? I though the same i2C commands existed for both.
Now, I would say it makes sense - there is no 24xxx I2C flash nor any 34xxx series mentioned in the driver.
Open up in Ghidra, as x86_64, Intel arch is able to read & parse, looking good to start:
This is the extracted body of the particular PE32 image from UEFITool - "FlashDriverSmm" in this case. (which has also all those flash-chip vendors)
Ok, in "
FlashDriverSmm" @ offset 0x000134f8 found probably something, where the flash-IC-vendor is set/choosen/identified:
- there is a section for ATMEL / ADESTO
- further code section for XMC, Cypress, Spansion 25FL(P), STM/Micron/Numonyx
- and one more for SST 25LF040 and SST 25LF080
(Now some of the addresses has to be either the Flash chip on I2C bus or the PSP-related interface which then translates the query and works with the flash. Here we don't know yet. Is it the CPU which is accessing the flash (therefore the BIOS, let's simplify first) or is it the PSP....)
Hmm I can imagine, that at some point, the FlashDriver is being told
which flash-IC to use, so it translates needed commands into the flash-IC-specific.
Ok, now we have to
find the module the actual flash-data is coming from.
I've done some reverse work on STM32 with an ARM M0+ core, which worked well (after hours and days of read-ups, etc) - at the end I was able to achieve desired results. Here we have to start from ground up again.
Smi == System managements interface, I guess - will dig inside this driver.
The "FlashSmiDxe" looks also good, and it's init section is bigger, so settings up
the addresses and default / awaited values may take place here. Somehow need to grep the I2C-flash-address :/
"FlashSmiDxe" has also no vendors or any model numbers in it's data (vs. "FlashDriverSmm"). So, can we assume the correct "FlashDriver" has been choosen at this point?
Feel free to discuss this topic and post your results.
Maybe we could compare the dxe-setup routine with Dan's logic analyzer's output? It should make sense at some point.
The protocoll should be inside the driver, so exactly the requests should be followed by ("same") responces - if they're not XOR'ed with a timestamp or something to obfuscate it for us. -- By now the output may be interpreted wrong and there could be a need of re-sampling again. I don't want to discredit, I just want to rule out "dead ends".
And whatis this last dependency, which is on stack in the "FlashDriverSmm"
but also in kinda all other runtime-related modules!?
However, the good news is - they are all reversable.
There is no luck I'm seeing myself accomplish the project due to couple of limiting factors. Time is being the most important one.
Therefore I'm open to people who want to get started with it, and will provide as much info as I can, to be able to grasp through this
topic all-together
