I got my Framework Laptop today and intended to use an older Corsair Force MP500 480GB drive in it but the computer just won’t get through to the BIOS when booting up. The display backlight turns on but then nothing happens. Diagnostic LED sequence is all green.
I put a 2TB Samsung 970 Evo drive I got last week (upgraded the 480GB drive in another system to 2TB) and that drive was recognized just fine. For some reason this Corsair drive is blocked in my new laptop and I have no idea why.
Doesn’t appear to be a firmware update I can run on my other computer. I did switch it from MBR to GPT with no difference.
The whole thing is just weird to me. I’ve never seen an SSD prevent a system from booting.
@GhostLegion I’ve formatted it, changed it from MBR to GPT, SMART seemed fine. It works in another system without issues but for some reason the Framework just doesn’t like it at all. I thought it might have been the slot but that 2TB drive booted.
I’m going to go pick up a WD SN 850 1TB drive soon. It just would have been nice to have used this one I already had.
Have you been using encryption on this drive? Maybe you need to do a PSID Revert?
Otherwise, I’d try DISKPART CLEAN on the machine where it works, possibly even CLEAN ALL (takes a while), and check the SMART readings again afterwards.
The drive is from 2016 it seems. Maybe there’s a compatibility issue with PCI-E 4.0. Theoretically you could also try reducing the PCI-E interface speed to see if it helps but the settings for this in the BIOS Setup are not exposed to the user, so it’d be cumbersome.
I’m afraid I don’t follow your logic. These are completely unrelated products. The MP500 is based on Phison PS5007-E7, while Hynix and WD (SD) use their own in-house designs. More importantly, as I wrote:
Which implies it’s unlikely it could have been evaluated for PCI-E 4.0 compatibility, unlike the two more recent SSDs that you mentioned.
I can’t even get into the BIOS with that drive installed. I could try disabling it with the drive removed and seeing what happens with it installed - but that shouldn’t prevent it from booting.
There has been no encryption on the drive.
I did take a look at the Corsair Toolbox utility and it didn’t recognize it. It is an old drive so there may be a compatibility issue but I’ve never heard of an NVMe drive preventing the system from POSTing before.
@BlueBird All 3 are PCIe gen 3 drives and gen 4 is backwards compatible with gen 3
Now I won’t claim to be an expert or electrical engineer so perhaps it is an issue with the controller but to my mind that shouldn’t be an issue
All controllers should be standardized in the functions they perform and what calls are necessary to perform those functions
One controller might be quicker than the other but they all do the same thing
Could you explain why the controller might be the cause?
Something else occurred to me, since prison controllers are used across a range of products, multiple drives across brands would suffer from this flaw and it would have been discovered by now if it was a problem between gen 3 and 4 platforms
It’d be useful to get it to work because it might offer a firmware update that resolves the problem. Also, if it doesn’t detect the drive now but it used to work for other people in the past, that’d also be an interesting data point.
You’re correct of course that it’s abnormal. Broadly, I think it’s most likely either: (1) failing to establish a PCI-E link or (2) failing to enumerate boot options. The “proper” way to proceed would be to read the BIOS POST code at which the boot sequence stops. I’m not familiar with the exact implementation, so just as an illustration, it could be something like 0x77 (PEI_PCIE_TRAINING), 0x13 (BDS_PCI_ENUMERATION_START),
or 0x27 (BDS_ENUMERATE_ALL_BOOT_OPTION), which would narrow down the issue to the either the former or the latter as the cause (or alternatively pinpoint another specific place where the problem manifests itself).
The meaning of the codes can be looked up in the documentation that is not officially public but can be found in various places on the Internet. Unfortunately, reading the code itself is non-trivial, so I didn’t even mention it initially.
Generally, for (2) you could try wiping the drive completely, re-initializing it as GPT, perhaps creating a single partition just as a test. For (1) you’d boot without the drive first and downgrade the PCI-E link speed in the advanced BIOS settings (which are hidden, so you’d also have to find a way around it first), and then re-insert the SSD to see if that helps. My guess is that it likely would but even if you could get it to POST with a workaround like that, it’s debatable whether you’d be willing to accept the associated decrease in performance.
What you could also consider doing: see if anything else is connected to the same PCI-E interface (Wi-Fi card?) and disabling or removing it, and testing the same SSD with another PCI-E 4.0 host (preferably also Intel).
What I had in mind referring to your previous post was that it’s likely a controller-specific issue, so other SSDs with different controllers (like the two you mentioned) would not be affected.
In theory it should all be compatible as you’re saying. But in practice the firmware (and hardware as well) often has all kinds of bugs, which have to be worked around with firmware updates, and that’s if they’re identified first through testing, and someone is then willing to allocate the resources to have them fixed.
It’s a combination of a relatively old SSD on a relatively new Intel platform. Not many people are likely to use the two together. Especially as it was a premium option at the time, and buyers in this market segment are likely to upgrade more often.
This was Phison’s first NVMe controller. There were just a couple of other designs with it: MyDigitalSSD BPX, Patriot Hellfire and PNY CS2030 Zotac Sonix (source: AnandTech). I doubt many of these have ever been used in PCI-E 4.0 systems. Still, even if they were, they might not exhibit the same issues, since it could be down to each vendor’s specific firmware tweaks.
The linked article (from early 2017) says by the time of writing only Patriot released firmware updates for this design, others (including Corsair) did not. And if they didn’t do so back then, they’re even less likely to have worked on any issues later when the product was approaching its EOL. Eventually, whoever at Phison worked with Corsair on the implementation will have just moved on to other projects, if not jobs, making the prospect of any fixes even more unfeasible.
For these reasons I wouldn’t exclude such an issue as the likely cause.
However, it also looks like Framework’s BIOS could implement some workaround to make the SSD POST correctly, even if it might have to be a performance-reducing workaround. Considering how helpful the Framework staff have been reacting to similar issues in other threads, @Avendor could consider contacting them to send them the drive for further investigation of this problem. All in all though, I think it was a good decision to just get a new SSD and take advantage of the significant performance gains that happened with the more recent generations of NVMe drives.
The drive worked in my desktop computer - a Ryzen 7 2700X system with a Asus Crosshair Hero VII Wifi board. Its worked in the main M.2 slots as well as a M.2 to PCIe adapter just fine. The adapter is what I used to see if the Corsair utility would recognize and update the drive for a firmware update but no luck there.
There might be some information in the bootcode readout with the blue/green LEDs but I’m not sure how to read it.
I went to Best Buy this morning and picked up a WD SN850 1TB drive and the computer boots successfully with it. I’ll look at buying an enclosure for the Corsair drive to just use it as a portable drive, so not all is lost. Unfortunately I don’t have any other PCIe gen 4 devices to test with.
I submitted a ticket to support about the boot issue yesterday when I didn’t know it was an SSD issue so I’ll follow up and link this thread. If Framework wants to know more I’m happy to help out!
The code is transmitted using the LEDs: after an orange signal, there should be 8 more flashes, each either blue (meaning 1) or green (meaning 0). Together, this should reveal the POST code, which in turn can shed more light on why the laptop is not booting with that particular SSD - if you want to try reading it.
Yes, these are the codes I was talking about, I just haven’t found a resource to interpret it. There is a table in a support article about how to interpret the green/orange lights before this, but not the blue/green bootcodes.