Is that FW16 mainboard using standard BIOS and EC firmware, or is it using a special development version?
I ask because, with my FW16, if no display or expansion bay or battery is plugged in, it would not boot.
I guess you setup has a display, and an expansion card plugged in, but I am curious.
I covered the chassis switches in white tack to make the main board believe that it was installed, and then did the same with the expansion bay hatch cover. It keeps flashing blue and red, but seems to boot totally fine so I expect it’s a non issue.
I’m calling it quits for the night because I’ve fallen into a mind mangling rabbit hole of trying to write the firmware to the expansion bay PCB. I’m so so so lost. Please, in a bit of a cry for help, would someone mind walking me through getting cosmopolitan set up and running the framework GPU extension on it? I’m sure any Linux wizard could help, but we’re slightly stuck if I can’t figure this out. Not sure if it helps, but this is the repo I’m trying to work with: GitHub - FrameworkComputer/ExpansionBayConfigurationGenerator: This repository contains example host code to generate Expansion Bay EEPROM Descriptors .
Thanks to anyone in advance who can spare some time 
I don’t know what you are intending to write. But if you have a EC CCD. There is a ec console command that writes one of two preset configs. One for the dual nvme, another for a gpu.
If one of those is good enough to get you up and running, I would use that as the easiest method.
There is also a backup current config. So you can take a backup, from say the gpu 7700 card, and then write it to your card. Or edit, then write.
Do you mean to say that it’s all already installed? I was under the impression that I’d have to install Cosmopolitan and the rest of the git repo to run the command. Have I completely misunderstood?
If you do your own config, then yes, install all the tools.
It you can reuse those two options I mention, all you need is a EC CCD.
E.g.
D Howlett sent me one of his, but he has published the designed on his public gitlab, so you can make your own if you wish.
I feel really stupid but does this refer to a piece of hardware or software? Do you mean something like this?
Yes, that one on this site:
The original gitlab is here:
and I have a backup of it here:
Hmm I’ve clearly got a conceptual misunderstanding here… do you mind if I DM you with some questions?
Okay I’ve got both exciting and less exciting news. Thanks to James3 I’ve got a grip of how to write the EEPROM to the board, and have successfully retrieved the .bin file from my 7700s to duplicate onto the MXM board. The bad news though is that the board isn’t being enthusiastic about receiving the firmware I’d like to write to it.
Here are the things I’ve checked so far:
The board definitely gets power (really exciting! 3.3V read)
There are no shorts, and nothing gets warm to the touch
All address busses, (A1, A2 and A3) are indeed pulled straight to ground, as I believe they should be? Buried deep within the “advanced commands” in the embedded control repo is a tiny mention that the Framework is expecting to write to I2C address bus 0x50. The datasheet for the EEPROM chip is locked with the first four digits of the address as 1010 - though this is a non-issue as I’m using exactly the same EEPROM as framework is. The final three bits then should be 000 to make it 1010 000 as a hex value 0x50. This also seems to be in accordance with the reference design for the dual m.2 adapter.
Write protection is definitely off, and pulled to ground with an 100k resistor:
Here’s the complete log:
Any ideas?
It looks like its trying to write to address 0, which makes me think it cant see the GPU EEPROM for some reason?
Oh I hadn’t even seen that. Weird - it should be set to default address 0x50. (though this actually is 1010 000 so maybe that’s not the problem?
hmm, maybe. I’ll do some more digging. The error message seems pretty explicit to me but I’ve been fooled before 
I’m not at all disagreeing but I’m confused as to how it could be the issue. The framework_tool doesn’t give the user any kind of granularity whatsoever as to which I2C address the chip can be written to - it’s locked and as long as I’ve designed the hardware correctly should be working fine. It also kind of seems as though it might have a connection with the chip? I tried framework_tool –expansion-bay -vvvv and got this:
thoughts?
Update: managed to get an old CH341A that I had lying around to connect up to the computer. Going to try and write the firmware to that first, and then I’ll try soldering the new chip to the old pcb. Fingers crossed.
Ok yeah, its definitely trying to write to the correct port then. I’m not an expert in this kind of software, but for i2c a “not acknowledged” can mean a lot of possible issues:
the code itself references this:
if self.i2c_status & 1 > 0 { return Err(EcError::DeviceError( "I2C Transfer not acknowledged".to_string(), )); }
so the first bit ofself.i2c_status is set to 1 and invoking that error.
So it’s establishing contact with the chip, but then the chip is failing to acknowledge it? In the mean time though, the Aliexpress CH341A has come in clutch! After a bit of messing around the firmware has been successfully written to the chip. Now I’ve just got to solder on the functioning one and it might actually, like, work!
Can you take an oscilloscope trace from the SDA pin of the EEPROM on your MXM expansion card, just to see what message is actually getting through.
Also, measure what voltage is on the A0, A1, A2 and WP pins.
I’d love to but I’m unfortunately not in possession of an oscilloscope.
Ok, in that case, just take a voltmeter and measure:
