Hi
I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember ever having to do this before. Why? If I have a clue I can code up and submit a patch.
If I recall correctly both my p2b and p2-99 boards do that while running vendor firmware, though I don't recall ever seeing it while running coreboot (which I just checked to verify it still doesn't show up).
Back to how it failed to boot in the first place. The hard disk booting stalled after SeaBIOS. Took me hours but eventually I found a line in my serial log that there has been a DMA timeout. Turning UDMA off in devicetree.cb and flash again made it boot again. So I would have to revert 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the reasonable thing to do and it should have worked. So I'm also unsure why it didn't.
I've had the occasional issue with my p2-99 in the past, but I've always got it booting again after reseating chips (flash/memory/cpu card). I guess I should be making sure to have the serial link set up more often, I normally only use it when I have a known bad version of coreboot flashed. I actually have the cable connected between the two boards right now, which seems to work decently for testing.
Branden
I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember ever having to do this before. Why? If I have a clue I can code up and submit a patch.
This happens if flashrom can't identify the chassis type via SMBIOS (type 3 table IIRC). Basically, it assumes that if the user is on a system that is likely to have an embedded controller (typically laptops) then it is unsafe to proceed since ECs often share the firmware ROM and may interfere with the update process.
So if you can fix SMBIOS to indicate that you are using a desktop board then flashrom shouldn't bother you with that.