merge / skulls Goto Github PK
View Code? Open in Web Editor NEWpre-built coreboot images and documentation on how to flash them for Thinkpad Laptops
License: GNU General Public License v3.0
pre-built coreboot images and documentation on how to flash them for Thinkpad Laptops
License: GNU General Public License v3.0
Hey, I was wondering what this is actually about: https://github.com/merge/skulls/blob/master/x230/x230_before_first_install.sh#L70
Since I was having a quite intense discussion with a friend about that, and if this may be needed at all.
From what we found in the wiki page which is linked in x230/README.md: https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge
I understood that the RAM voltage can only be adjusted on some Sandybridge/Ivybridge boards, but support for that is not implemented within coreboot, so RAM voltage is always fixed to 1,5V on the X230 and all Sandybridge/Ivybridge boards.
We also did a lookup and understood that PC3 is always 1,5V and all PC3L modules can run with either 1,35V or 1,50V: https://en.wikipedia.org/wiki/DDR3_SDRAM#DDR3L_and_DDR3U_extensions
so both PC3 and PC3L must work in the X230, which will always run with 1,5V.
Am I missing something or can this check be removed alltogether, or at least for the X230? Thanks
I use skulls 0.1.0 and its released non-free images. Everything works so but but not resuming from hibernate. These are the regarding boot msgs trying to resume:
Jan 03 11:42:16 rocinante kernel: PM: Image signature found, resuming
Jan 03 11:42:16 rocinante kernel: PM: resume from hibernation
Jan 03 11:42:16 rocinante kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Jan 03 11:42:16 rocinante kernel: OOM killer disabled.
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0x0009f000-0x000fffff]
Jan 03 11:42:16 rocinante kernel: PM: Marking nosave pages: [mem 0xbff0d000-0xffffffff]
Jan 03 11:42:16 rocinante kernel: PM: Basic memory bitmaps created
Jan 03 11:42:16 rocinante kernel: PM: Using 3 thread(s) for decompression
Jan 03 11:42:16 rocinante kernel: PM: Loading and decompressing image data (702020 pages)...
Jan 03 11:42:16 rocinante kernel: Hibernate inconsistent memory map detected!
Jan 03 11:42:16 rocinante kernel: PM: Image mismatch: architecture specific data
Jan 03 11:42:16 rocinante kernel: PM: Read 2808080 kbytes in 0.01 seconds (280808.00 MB/s)
Jan 03 11:42:16 rocinante kernel: PM: Error -1 resuming
Jan 03 11:42:16 rocinante kernel: PM: Failed to load hibernation image, recovering.
Jan 03 11:42:16 rocinante kernel: PM: Basic memory bitmaps freed
Jan 03 11:42:16 rocinante kernel: OOM killer enabled.
Jan 03 11:42:16 rocinante kernel: Restarting tasks ... done.
Jan 03 11:42:16 rocinante kernel: video LNXVIDEO:00: Restoring backlight state
Jan 03 11:42:16 rocinante kernel: PM: resume from hibernation failed (-1)
My dmidecode details:
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: coreboot
Version: CBET4000 4.8-2601-g2ca2acc51f-dirty
Release Date: 12/19/2018
ROM Size: 12288 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
BIOS is upgradeable
Selectable boot is supported
ACPI is supported
Targeted content distribution is supported
BIOS Revision: 4.0
Firmware Revision: 0.0
There's also S3 breaks system memory but that issue refers to sleep mode (suspend to ram).
What'd be nice to have is a live USB system with
If you have experience with creating live iso images, please help. Actually, adding flashrom (+dependencies) to https://github.com/ivandavidov/minimal would be enough...
I just used your config and latest version of coreboot and after adding additional payloads (tint, nvramcui, etc.), I am unable to start them.
Laptop just reboots.
I will try to flash your image right now, just in case it is problem with my build enviroment.
Edit:
With your image, nvramcui does work.
Any ideas what could be wrong with my enviroment?
I have just created build enviroment for building heads nightly.
I figured out most of things I do not like about heads are solved by your config.
Do you think we can collaborate in some way to make it better?
sudo ./external_install_top.sh -k x230xbackuptop.bin
No image file found. Please add -i
Skulls for the X230
Run this script on an external computer with a flasher
connected to the X230's top chip (closer to the display
and farther from you)
Usage: ./external_install_top.sh -i <image.rom> [-c ] [-k <backup_filename>]
-f <hardware_flasher> supported flashers: rpi, ch341a
-i path to image to flash
-c to use for flashrom
-k save the current image as
-b frequency of the RPi SPI bus in Hz. default: 128
Since 20180108 seems to have "reboot" issues, see https://newsroom.intel.com/news/firmware-updates-and-initial-performance-data-for-data-center-systems/ we currently only "prepare" to include a new microcode release in coreboot upstream.
As https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088 suggests, there could be a new release "soon". By then we hopefully have enough review upstream on how to include it and it all goes without much delay.
... It might not even affect the X230, since the 20180108 package, for X230's CPU model has updates from up until onyl 2015-02-26. Nevertheless: currently in coreboot we have an older version (from 2014), so we want to have it included.
There is a minor mistake in x230_i5_coreboot_seabios_533ea7adb5_top.rom.sha1
file:
sed 's/x230_coreboot_seabios_533ea7adb5_top.rom/x230_i5_coreboot_seabios_533ea7adb5_top.rom/'
I have my boot SSD (mSATA, Samsung) in one of the miniPCIe slots replacing the WWAN module and another drive (Crucial) in the 2.5" bay. SeaBIOS first tries to boot off of the drive in the bay, but that doesn't have any MBR and so it falls back to the payload (nvramcui
). This means I explicitly have to invoke the boot menu using Esc to select the mSATA SSD.
Not sure if a way to change the boot order could be integrated into the build.sh
script? At least I'd like to document the process here for someone with the same problem:
SeaBIOS boot order documentation
SeaBIOS reads the boot order configuration from a "file" in CBFS which is part of the coreboot ROM. This file has to be called bootorder
and includes a boot entry per line in a somewhat cryptic format (apparently inspired by Open Firmware) e.g. /pci@i0cf8/usb@10,4/*@2
. This boot order file can be integrated into the coreboot build process using the SEABIOS_BOOTORDER_FILE
Kconfig option.
The best way to get the boot order strings is to extract them from the coreboot debug log. This can be accessed using cbmem
from coreboot-utils (output abbreviated):
# cbmem -c
[...]
Searching bootorder for: /rom@img/nvramcui
Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0
AHCI/0: Set transfer mode to UDMA-6
AHCI/0: registering: "AHCI/0: Crucial_CT750MX300SSD1 ATA-10 Hard-Disk (698 GiBytes)"
Searching bootorder for: /pci@i0cf8/*@1f,2/drive@2/disk@0
AHCI/2: Set transfer mode to UDMA-6
AHCI/2: registering: "AHCI/2: Samsung SSD 860 EVO mSATA 500GB ATA-11 Hard-Disk (465 GiBytes)"
[...]
Press ESC for boot menu.
Select boot device:
1. AHCI/0: Crucial_CT750MX300SSD1 ATA-10 Hard-Disk (698 GiBytes)
2. AHCI/2: Samsung SSD 860 EVO mSATA 500GB ATA-11 Hard-Disk (465 GiBytes)
3. Payload [nvramcui]
t. TPM Configuration
[...]
The important lines here start with "Searching bootorder":
# cbmem -c | grep "Searching bootorder"
Searching bootorder for: /pci@i0cf8/pci-bridge@1c/*@0
Searching bootorder for: /rom@img/nvramcui
Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0
Searching bootorder for: /pci@i0cf8/*@1f,2/drive@2/disk@0
Searching bootorder for: HALT
From the first cbmem
output above I can infer that /pci@i0cf8/*@1f,2/drive@0/disk@0
refers to the Crucial SSD and /pci@i0cf8/*@1f,2/drive@2/disk@0
to my mSATA boot SSD from Samsung. To boot from the mSATA SSD by default, I have to create a bootorder
file with something like this:
/pci@i0cf8/*@1f,2/drive@2/disk@0
/pci@i0cf8/*@1f,2/drive@0/disk@0
/rom@img/nvramcui
I have tried installing mktemp but the problem still persists
pi@pi:~/Downloads/coreboot $ sh flashrom_rpi_bottom_unlock.sh -c MX25L6405 -m
make: Entering directory '/home/pi/Downloads/coreboot/util/ifdtool'
make: Leaving directory '/home/pi/Downloads/coreboot/util/ifdtool'
-e Intel ME will be cleaned.
-e The flash ROM will be unlocked.
Start reading 2 times. Please be patient.
flashrom_rpi_bottom_unlock.sh: 101: flashrom_rpi_bottom_unlock.sh: [[: not found
flashrom_rpi_bottom_unlock.sh: 101: flashrom_rpi_bottom_unlock.sh: -d: not found
-e Error: Could not create temp dir
Take time to flash a recent 4MB image with Intel's microcode included, test and verify. For the release:
sudo ./external_install_bottom.sh -m -k x230sbackup.bin
Skulls for the X230
Please select the hardware you use:
Error: Extra parameter found.
Please run "flashrom --help" for usage info.
Your readme states that the X230 is supported, but I'm not an expert enough to know for sure if that includes the X230t as well. Could you update your readme to explicitly affirm or deny support for this variant? Thank-you!
I flashed 0.0.3 to my x230 and Windows, even in safe mode, hangs and won't boot. After flashing do I need to reinstall windows? What is the expected behavior?
in case you noticed, I renamed the project. If you feel like it, please post a suggestion for a logo. It can be a hand-drawn draft that can later be put into a vector-graphics file. My drawing skills are rather limited. Oh. and if it's a skull, it should be a friendly one :)
background: Basically I renamed and refactored the project to make room for more. We plan to add more hardware flashers to the x230 docs/scripts and the README became quite large already. Now we separate device-independent stuff out.
Also we have room for any other device now, in case you have one and think that flashing could be simplified. I certainly don't plan to myself, but why not.
Feedback and changes are always welcome. thanks so far.
I might have some time in next few days to do this.
This can be very useful...
Edit:
Upstream docs:
flashrom -p internal
really not possible for an original Lenovo BIOS?Also, create a flashrom-wrapper (and even include the flashrom program itself?) for writing (read 2x, compare, go on if ok, ...)
That way we'd save a lot of time for first-time flashing. It'd be "hit one button" (twice) on the RPi, instead of the quite involved process it is right now...
This is really just loud thinking. I'm happy for any input. The X230 has an accelerometer chip connected to the EC. Let's see how far we can get to reading it's values.
So a first step seems to be fiddling with CONFIG_ACPI_EC_DEBUGFS
interface. At least we could find out if it's active and saving values by default.
Is there a HDAPS mode interface anywhere for us (without accelerometer access support) you know of, that we could try to turn on?
I've successfully flashed coreboot onto my x230 and it boots without problems, but I wasn't sure how to tell if the microcode from the Windows/Lenovo updates was properly integrated into the coreboot-ed bios. Is there a standard way to ensure that it was copied? How do I confirm this?
Thanks!
Basically we need to have the microcode version information. It should be tested well before releasing.
nvramtool: CMOS option table not found in coreboot table. Apparently, the coreboot installed on this system was built without specifying HAVE_OPTION_TABLE.
We want to do a release soon. There's a new microcode revision 0x20
released via Lenovo, and a SeaBIOS release 1.11.2. Both changes we want to have are put up for review:
I expect at least the microcode change not be included in coreboot's master branch immediately. The SeaBIOS update probably will be, and if we're lucky we can drop it here when we release.
When we have it up completely, we should (at least try to) include them in our build scripts (cherry-pick) so that we get a reproducible build again.
If you want to have our documented setup on your X230 and cannot do it yourself, you shouldn't be totally out of luck.
I offer to do the whole flashing procedure for you, flashing the latest release we have here, and applying me_cleaner and all that fun, as I have time.
You'd need send the machine in to me and cover shipping costs (and optionally add a tip) via BTC 1EH4Y37Zgves8YHJybLA9mw5aaqS7BtLs7
or LTC LeNrCxfdZ3qJMjTjjKU4z4brDfNAjrpBWE
. Details by email: [email protected]
Also, sometimes I might have an X230 available to sell. Ask if you're interested.
Also, if you would offer to do the same, free to reply here and do so.
We had very few reports of permanent bricks @ coreboot over the years. But all those I can remember were about the ThinkPad X230 and involved VCC supplied directly to the flash chip (which you should never do anyway unless the VCC is protected with a diode or something because you'll violate the board's power sequencing).
Therefore, we recommend to use the laptop's own PSU to power the flash chip. On the X230, the flash chips should be powered when the laptop is in S5, listening for Wake-on-LAN messages. Usually you can enter that state when you remove all batteries, plug a LAN cable (with active remote) and then plug the PSU.
Although I've never heard of permanent bricks using that method, the actual problem is not well studied. So I'd recommend to flash only the minimum externally, i.e. the 4MiB chip and optionally unlock the firmware descriptor.
NB. saying the BIOS only fills the second chip is not accurate (it starts at 5MiB in the first chip), though that simplification works in the coreboot case with CBFS_SIZE<=4MiB.
first: we don't (yet) want to advertise internal flashing. It still feels like it could be dangerous. BUT:
In case you do, how do you do it? Is there a way for flashrom to take the 4MB "top" image and write it to address 0x00800000
(from 0x00800000
to 0x00bfffff
) instead of starting at 0x00000000
?
If that cannot be done: We should actually create a script that:
The thing is, I want to stop distributing the 12MB image. It should really be generated by users (the bottom 8MB are useless).
As a sidenote, I want to think about how to do releases. Strictly speaking we should include Intel's microcode license. And if we add a script for internal flashing, described above, we should probably create a tarball.
Is there a configuration for having Video pre-Linux (in SeaBIOS and bootloader from HDD) without the binary VGA BIOS rom extracted from the vendor image?
When building using our "free" config (mv config-xxx backup-config-xxx && mv free-config-xxx config-xxx && ./build.sh
) we don't have early linux boot console output on the display.
GRUB_TERMINAL=console
is set?Also, GRUB doesn't use the full screen in the framebuffer, but that's probably fine. It uses the same resolution as with Intel's vga bios binary.
I'm thinking about finding heuristics, that would choose a working flashrom chip for us. We could:
flashrom -p ... &> temp_flashrom.txt
cat temp_flashrom.txt | grep <chip>
and save if found-c
commandline option.I hear this is the Right Way to execute that.
For a while now, USB always on is supported in coreboot: https://review.coreboot.org/cgit/coreboot.git/commit/src/mainboard/lenovo/x230/cmos.default?id=7ffb329f278d6b027bb3b3660b69e87f1ddd69d8
But the default config does not enable it. Would it make sense to enable here? I personally find it a very useful feature.
As much as I like buying stuff locally, it'd still help our cause if we'd have links to shops that ship the pomona clip and jumper cables worldwide (or multiple if regional only).
Would you add such links? If yes, how and where?
If at all, I'd even add a serial cable for the RPi. (And yes, for people who don't own a RPi we should include the ch341a, but we'd have to document it's usage first.)
What came out of #4 so far is that we could release an alternative config / image, without Intel's VGA Bios binary. For Linux users everything seems to work, but without framebuffer graphics, like we have it currently, only text-based. For GRUB users that means, GRUB_TERMINAL=console
has to be in /etc/default/grub
. A tested config already is the repo, named xxxxxxxxxx_free.config.
I compiled coreboot for myself a while back. I'm looking into the project and would like to know if I can upgrade my coreboot to a skulls release. The documentation suggest I run the external scripts before I run prepare_internal_flashing.sh.
My question is can I up grade my bios by adding iomem=relaxed to my kernel parameters and run the script?
Also how would I be able to check if my bios is unlocked and eligible for the upgrade?
If this has been answered my apologies, looked at closed issues and I couldn't find information on this.
4MB chip:
MX25L3206E
works for me so far8MB chip:
MX25L6406E/MX25L6408E
seems to workMX25L3206E/MX25L3208E
works for me tooShould we just have "first time installation" and "updating" sections, with the hardware flashing "examples" (only RPi for now) in the former, and the internal flashing in the latter? Is internal flashing always "safe"?
I don't quite like how we have things split up right now in the README. I guess we should change it. And a note in "updating" that alternatively one still can flash externally, using the flashrom script, would be enough.
... if you know what I mean -.-
It seems that my X230 Tablet model (i7) actually has two 8MB flash chips instead of 4MB+8MB.
I have a CH341A USB flasher and it reads the two chips as follows.
Upper one:
flashrom --programmer ch341a_spi
Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on ch341a_spi.
Bottom one:
flashrom --programmer ch341a_spi
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E" (8192 kB, SPI) on ch341a_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E"
Please specify which chip definition to use with the -c option.
I cannot flash the coreboot toprom, because it's only 4MB. Am I doing something wrong here?
I think a script to build the binary ROM locally would be a great addition. This wouldn't be too difficult, I wouldn't think - just pulling the files from skulls and coreboot repositories, and then running the compilation commands.
It would be great to clarify the difference between the free and nonfree image in the x230 README.
I.e.
Random resets settings after a reboot.
We want to make it easy to quickly "bootstrap" the X230 to a working, unlocked, easy to use coreboot-based flash image system; SeaBIOS is great for this!
There surely are users that want to move on to HEADS from there, especially when some of purism's work is merged. I'd love to have this tested (and documented maybe).
x230_update.sh
What the current state of TPM usage, when me_cleaner is applied? Is it usable? If not, does the --keep-modules
option keep the TPM usable?
In the x230 README.md there's a note about RAM voltage. Is the 1.5V restriction a permanent one or is it related to the flashing process?
when going into sleep, the computer sometimes fails to recovery and either restarts and fails to restart. How can I Debug, this issue.
I would love if one of the bios already had the fn and ctrl key swapped. Chatting in the coreboot irc channel and searching the web has not produce much results in how to make this happen. So just having it ready for those that one it from the get go would be great. I feel it is something that most thinkpad owners change more than any other bios setting. The other option I think would be creating a resource on this project for how to do it if you don't want to include it in the bios release would be very helpful for those that want to do it.
I am not sure if this fits with the philosophy and goals of Skulls but what about incorporating an EC patch that disables the authentic battery validation check?
http://zmatt.net/unlocking-my-lenovo-laptop-part-3/
https://github.com/eigenmatt/mec-tools
https://github.com/hamishcoleman/thinkpad-ec
I was wondering if we can set the battery thresholds similar to this https://www.coreboot.org/Board:lenovo/x230#Setting_battery_threshold_on_a_X230_with_coreboot. I would like to be able to do this from the config payload if possible. But it may require additional dependencies if ectool is needed.
SeaBIOS 1.12.0 is released and we've put the coreboot-update up for review: https://review.coreboot.org/#/c/coreboot/+/29724/
I've run it and it looks good. Let's wait a week or so for coreboot to integrate it before we do a release with it.
We expect needing to extract the newest microcode binary from a vendor's BIOS package.
1f
on March 23rd; probably at the X230 support pageA declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.