skulls

skulls copied to clipboard

A few times after I flashed skulls/coreboot onto an x230 board, the board doesn't boot anymore. On pressing the power button, the power button LED flashes 3 times and then there is no further response or boot progress on the motherboard.

I tried to flash the backup of the lenovo ROM that I had made while flashing skulls but that does not fix the situation. In case anyone has any tips on this, I'd be grateful. I have 3 motherboards now that don't boot after flashing coreboot.

what hardware flasher do you use?

Am 24. Juni 2019 18:57:16 MESZ schrieb Abhas Abhinav [email protected]:

A few times after I flashed skulls/coreboot onto an x230 board, the board doesn't boot anymore. On pressing the power button, the power button LED flashes 3 times and then there is no further response or boot progress on the motherboard.

I tried to flash the backup of the lenovo ROM that I had made while flashing skulls but that does not fix the situation. In case anyone has any tips on this, I'd be grateful. I have 3 motherboards now that don't boot after flashing coreboot.

-- Martin Kepplinger http://martinkepplinger.com sent from mobile

I'm using the ch341a for flashing these days. I had a similar case while using a raspberry pi 3 earlier.

what hardware flasher do you use?

In addition to the above, @abhas have you checked that voltage is within required tolerance?

I haven't checked that. Let check that out.

Should I check this out at the level of the SOIC clip? Or shall I check this at some other point on the motherboard? Would the voltage levels vary over multiple flash attempts with the same hardware flasher and the same clip?

If I am able to write to the flash chip and read from it afterwards and if the checksum of the read ROM is the same as what I'd written, then that might indicate that the flash chip is working fine. In that case, what role might the voltage levels play?

On the clip. Looking at MX25L3205 spec, it should tolerate 3.3-3.6v range, but I'd stay as close to 3.3v without jitter as possible.

Checksum is, AFAIK, reliable indicator. Apart from that, might worth checking if EEPROM isn't fried (opposite side of the M/B).

Flashed the x230 yesterday using rpi b+ and It doesn't boot anymore. In my case power button lights up for a couple of seconds and that's it. I've flashed vendor bios again and still bricked.

I was super slow following the instructions as it was the first time flashing so not sure what went wrong. I wonder If I can provide any feedback to the project? I still want to switch to coreboot.

@kobajagi How many copies of the original firmware code do you have? And are all the hash values of those copies the same? Make sure the speaker is connected. Are you getting any beeps?

I only have a single backup unfortunately (what the sculls scripts created). Didn't know I should make more. I am also not getting any beeps at all and speaker is connected (to be fair I don't recall if it worked before).

As there was no script for it, this is the command I've used to flush back the vendor bios:

flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -c "MX25L6406E/MX25L6408E" -w backup-upper.rom

Command for the bottom chip was similar (different chip). As for more context, I've updated bios first and patched it using thinkpad-ec (confirmed working after that).

Your command line looks fine. Which BIOS update did you apply?

Using Lenovo software, whatever was latest official update at the time. I've updated it almost a year ago so I don't recall the details. Laptop remained it the drawer all this time (didn't have tools needed for flashing back then). But x230 booted fine just yesterday before flushing.

Anything I can try/test to provide more info? I've bought the laptop for the purpose of experimenting with coreboot (and spare parts for my main laptop) so I'm OK if I break something in the process.

Just to be clear, it was about a year ago since you updated the BIOS. It has not been updated within the past few months. I believe the most recent update is suspect.

Then, my approach would be to restore (rollback) the laptop to the last known good (LKG) condition. That would mean flashing the backups. A few precautions: 1. make sure to disconnect power from the laptop battery and the RTC battery, and 2. make sure you select the correct EEPROM for each flash. Also, personally, I'd flash each three times.

Pay attention and make sure that flashrom successfully verifies the flash.

If all that goes well and you still have a bricked machine, then I'd suspect firmware image corruption. In that case, you'll want to use an image from another machine to get your laptop back to LKG condition. Many people have images they'll share with you. Just make sure it's compatible with your EC version.

Just to be clear, it was about a year ago since you updated the BIOS. It has not been updated within the past few months. I believe the most recent update is suspect.

Yup, BIOS update was a year old. I've read about issues with the new EC version and didn't want to update.

I didn't remove the RTC battery before, wonder if that was the issue? I will try flashing vendor again couple of times (only really tried once) and let you know if I made any progress.

Well, we are programming the EEPROM in-circuit. That creates many variables. For example, your programmer might be trying to "charge" the RTC battery. At factory, they put these chips in a gang programmer. They program them in bulk and at a higher voltage. It's best to pull the EEPROM and put it in a programmer. But, as hobbyists, we do what we can.

I have some update with my issue. It turns out I've broken off a resistor that is right next to EEPROM. I do recall having problem attaching the soic clip to the lower chip, so likely happened then and as resistor is super small I didn't notice it for a long time. Anyway I bought a replacement motherboard and will attempt to flash skulls again.

I am in a similar situation with T430 & no idea how to move forward, were you able to figure out what went wrong in your case? Was the power supplied by RPi more than the threshold?

might worth checking if EEPROM isn't fried (opposite side of the M/B).

How do we check that?