After locking me/txt region, disabling early boot console messages and postcar console messages (and couple other things I can’t really remember even though they seemed mildly innocent) my machine was rendered unbootable.
Then of course as a rookie mistake I took out my ch341a programmer and tried external flashing. I think I burned/broke this chip (hopefully not the whole board!) exactly like I did to another mobo months ago and forgot.
I got a couple of no chip/eeprom found errors in flashrom(just used the one that came with pureos, didnt compile). The red ‘run’ light was dimly on (it means the programmer can see the chip but there’s not enough power to read it)
I remember reading somewhere this random guy suggesting in that situation when programmer does not have enough power, plugging in the mobo without turning it on could make programmer work. So I plugged it in without booting and tada, no more dim light and still getting No EEPROM/flash device found after that.
I was doing this on the chip at the bottom side of the motherboard close to the front usb2 ports. I think either the chip or the whole board is toast. Shoul I buy a 16mb chip and try to flash/solder?
honestly, it sounds like you should hand things off to someone who knows what they are doing, since you are in the habit of breaking boards. You should not have tried to read/write the chip with the mainboard powered. You’re probably connected to the wrong chip. You’re making incorrect assessments and jumping to incorrect conclusions. You could have asked me about any of this and yet you kept digging yourself deeper in the hole.
You probably haven’t managed to damage anything yet. The dim red light on the ch341a meant that the vcc pin on the chip you were connected to wasn’t blocking power to the rest of the board, a sure sign that you either had the chip clip reversed, or were connected to the EC flash instead of the main firmware/BIOS chip.
I think I didn’t want to ping you in all occasions but thank you for saying that. I saw the dim red light again so the chip is probably alive 
Now there are 3 chips similar to each other on the backside of the board.
One I used was (U49) winbond 25128JVSQ (Can’t see model number well but it’s close to that)
There’s also a narrower one APL5934(…)
There’s the only one with a detectable white paint on it: winbond 25Q (?) SVG
the correct chip will be either a Winbond 25Q128xx or Macronix 25L128xx. If the red light dims, then it’s the wrong chip or connected backwards. Mine has a Winbond 25Q128JVSQ, and it’s located next to the screw hole at the corner of the SoC chip. The HSF assembly must be removed to access it.
Yep that’s the one, I’ll watch another video about choosing the wire placement. Could it also because I’m using a generic flashrom?
I looked inside the script to do what it did but was unsuccessful:
git clone —single-branch —branch master https://review.coreboot.org/flashrom.git
git fetch origin
git show c64486b
cd…
Also tried git reset —hard c64486b
make (…)
flashrom 1.2 from any repo is fine, the ch341a is long supported. Wires should just be 1-1 for all 8 pins.
Did it successfully, feels like ‘from zero to hero’. My motto is “Flash the chip first and ask questions second.” Haha…
So which one of these changes might have been the culprit?
(Edit: Leaving just the ones I know to be problematic)
Unticked>Include coreboot .config file into the rom image
Stage cache for acpi s3 resume>disabled
Disabled acpi pm timer
Set x2apic mode
Lock ME/TXE section
Ticked>Use onboard vga as primary video device
Unticked>Use legacy-BIOS alt-century byte in CMOS
Unticked>Enable early (bootblock) console output
Unticked>Enable console output during postcar
Unticked>Send console output to a CBMEM buffer
System Tables> Changed SMBIOS serial number/Manufacturer Name/Product name
Manually changed fsp_params.c to disable HT
Edit: Tried without locking ME and without Primary VGA setting, still didnt work.
Edit2: I remember reading someone mentioning choosing “x2apic” or “support both xapic and x2apic” options didn’t work for him on reddit. Maybe that’s it?
why did you change all of these items without understanding what they do? That’s a certain recipe for a brick.
quite possibly
In my own defense, everybody bricks some mobos on the way of learning right.
Now, I’m not gonna touch most of those but are these okay to change according to your knowledge?
- Changing system tables (serial no, name)
- Disabling console outputs
sure, but changing multiple things at once, when you don’t understand what they do, is not a sane way to test changes
the serial number is completely arbitrary and affects nothing. Changing the name can break DMI quirks in the Linux kernel
they’re already disabled, unless you mean the cbmem console in RAM, in which case I would recommend leaving it enabled
How come the date & time persist through reinstallations/machine staying without electricity for long period of time?
Also why is my bios name coreboot(…)-dirty
dirty?
that’s not your bios name, that’s the build string. It’s appended with dirty because your git repo is dirty - ie, you have uncommitted changes. It means your build is not reproducible.
What about the timekeeping anomaly?
I’ve flashed the firmware, removed the battery from the motherboard for around an hour but it still kept the date and time which is new for me.
the EC caches it somewhere I guess
Something shady is going on with newer technology I’m tellin’ ya.
Anyway, I’ve disabled virtualization by 3 different means, windows shows me its disabled but PureOS lscpu shows me
Virtualization: VT-x
1- Make menuconfig > Enable VMX (Unticked)
2- Make menuconfig > Set IA32_Feature_Control lock bit (unticked)
3- fsp_params.c > tconfig->VtdDisable = 1
at this point, we’re well off the topic of this thread, so best if you start another one for any issues/questions surrounding building your own custom coreboot image
Can I copy an older microcode to a directory and use it when I’m building coreboot?
I can point to it in the menu however I am only flashing the Bios and not ME since I have it locked. Would that work?
sure, but I don’t recommend that
The earliest microcode you used for libremv2 was 806EC_plat_94_…00D6 dated April 2020. The first microcode release after i7 10510u’s release date is (After Sept. 2019)
806EC_plat_94_…00CA Dated Nov. 2019.
Interesting thing is, the 806EC_plat_94 microcodes go back to B2 which is dated Feb. 2019.
So even though this CPU was released later, earlier versions of microcodes are available for it.
