as I can always reflash with the stock ROM I've decided to give it a try and splitted the generated 12 MB coreboot.rom as mentioned in my last email:
> to flash the upper 4 MB part of the BIOS:
> dd of=x230-4mb.rom bs=1M if=build/coreboot.rom skip=8
> to flash the 8 mb chip I'll try:
> dd of=x230-8mb.rom bs=1M if=build/coreboot.rom count=8
After flashing those files to both chips the Laptop boots up fine and I can boot Qubes and also Windows including graphics.
Unfortunately the two added Payloads are not working:
I get only a black backlight illuminated blank screen when hitting ESC and choosing one of the secondary Payloads.
My guess is, that something with the CBFS filesize is not correct, I've set it to 0x400000.
Any idea how to investigate this problem further?
Question: Is the above approach correct? I tried so already once but it didn't work (short flashing of Power-On-button -> nothing more) 
the x230 is quite good working,
... but recently some boards died (I know from 2 boards over the last
years). I'm still not sure why they died, but rumors that the EC
firmware ran into a bug when doing In-Circuit flashing.
I've an x230 myself and never managed to trigger that bug. I would
recommend you to update the EC to the newest firmware. The EC firmware
is updated together with the bios, so updating the vendor bios/uefi is
We can also desolder your spi chip, programm it and put it back. But
that's also a way I wouldn't recommend doing to often.
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
> -------- Original Message --------
> Subject: Re: [coreboot] Coreboot on X230 and Dualboot / How to make it work
> Local Time: 26 September 2017 12:49 PM
> UTC Time: 26 September 2017 10:49
> From: one7two99(a)protonmail.com
> Next step is to clean the flashregion_2_intel_me.bin (me.bin) with me_cleaner which is describe well.
It seems that ME_cleaner is now included in Coreboot looking at the options in menuconfig. As such I asssume I don't need to manually clean flashregion_2_intel_me.bin (me.bin)
The extracted Blobs are located at ./3rdparty/blobs/mainboard/lenovo/x230 and have been proper renamed and I have enabled the options under "Chipset":
*** Intel Firmware ***
[*] Add Intel descriptor.bin file
[ ] Configure IFD for EM100 usage
[*] Add Intel ME/TXE firmware
[*] Verify the integrity of the supplied ME/TXE firmware │
[*] Strip down the Intel ME/TXE firmware
[*] Add gigabit ethernet firmware
I have enlarged the CBFS under coreboot nconfig in "Mainboard"
ROM chip size (12288 KB (12 MB))
(0x100000) Size of CBFS filesystem in ROM
0x100000 wasn't enough, so I tried 0x200000 which was enough to add corinfo as secondary payload. Adding also nvramcui would need a bigger CBFS.
The later works if I increase the size of CBFS to 0x400000, as such I've proceed with this CBFS size.
I've read https://www.coreboot.org/CBFS but honestly, this information is currently more than I can understand (not a hardware hacker :-).
When I look at the picture from me_cleaner...
... the pictures explains to me that the Chips consists of several "areas":
Descriptor / GbE Blob / ME Firmware Blob / BIOS
Is the CBFS something like a "container" within the BIOS, which would mean that if I want to increase the size of the CBFS over a ceratin point I need to shrink ME Firmware (which is covered by the documentation from me_cleaner).
What would be the maximum CBFS size I can use without further modifications to the ME Firmware or will Coreboot reduce the size of the ME Firmware area to gain additional space automatically?
Now the obvious last step is to split the 12 MB coreboot.rom into two parts to flash the upper 4 MB chip and the 8 MB chip (which should include the "cleaned" version of Intel ME, as I have enabled "Strip down the Intel ME/TXE firmware" in the coreboot config).
Getting the last 4 MB of the coreboot.rom is covered by the coreboot wiki:
# to flash the upper 4 MB part of the BIOS:
dd of=x230-4mb.rom bs=1M if=build/coreboot.rom skip=8
to flash the 8 mb chip I'll try:
dd of=x230-8mb.tom bs=1M if=build/coreboot.rom count=8
Is the above approach correct? I tried so already once but it didn't work (short flashing of Power-On-button -> nothing more)
One7two99 via coreboot wrote:
> From a newbie perspective I'd like to get this information from one or two locations:
> 1) How to get Coreboot running (general part)
> 2) How to flash the X230
Sure thing - and I think it's great that you are working on more
The 1) is quite a large topic.
> > So you flash only the last third of the CBFS, and ignore the beginning.
> > I think it is just luck that your system boots at all. If you used a
> > larger payload such as a kernel then your method will likely cut the
> > payload in half and end up writing incomplete junk to your flash.
> I've followed the howto in the coreboot wiki:
Sure, but what do the steps in the howto actually mean? Why are you
sure that they are correct?
> honestly I was also wondering why this is working and even more,
> why I am skipping the first 8MB of the file.
Perfect! Please also *answer* those questions; they are important.
> Honestly I am trying to understand as much as I can,
> I am happy to contribute to the documentation to make it easier for
> the next newbie who might not be interested in how his CPU works,
> but wants to reduce possible entry points which might break his
> privacy :-)
Documentation contributions are just as important as code, and again
I really appreciate that you are working on this.
Sorry, I didn't mean to say study the CPU (though that's also relevant
for privacy; see AMD microcode paper with modified instruction exploit
to leak crypto key) - I meant study what's going on with these two
flash chips, since you want to change the contents of one or both.
What do the 12 MB flash contain, what is the structure, what determines
the structure, what can you change, how do you change, what *can't* you
change, why, and so on.
My point is that if you want to create documentation with exact steps
which can be repeated by the next newbie, then you will have to make
a whole bunch of very specific decisions, so that they don't have to.
Just saying to hang in there, continue understanding.
Am 26.09.2017 02:20 schrieb One7two99 via coreboot:
> I tried to flash the 8 MB Chip on my X230, but it didn't worked out.
>> Me: what do I need to do to flash the 2nd (8MB) chip.
>> If the 1st chip contains the last 4MB of the file, I assume the
>> correct command could be:
>> dd of=chip8mb.rom bs=1M if=build/coreboot.rom count=8
>> Is this correct? If this is right I'll add this to the wiki as soon
>> as I have write permissions.
> I've dd'ed the first 8MB of the coreboot.rom file with the above
> command and flashed it on the 8MB chip, but when booting my machine
> only illuminated the on-off-button for a second before it dies.
> When reflashing the 8MB chip with the stock image which I grabbed
> before will bring my laptop back to life. As such it seems that there
> must be another was two flash both chips and to strip the coreboot.rom
> Any ideas what went wrong?
> As all howto's I've found so far, which cover the flashing of only the
> upper 4 MB Chip, the question is also, if someone has already flashed
> both chips and what (s)he did to make it work.
what would you want to do? Analyse the image. If your BIOS fits in 4MB,
you really only need to flash the last 4MB, and using a hardware
you cut it out and flash it to the one 4MB chip. done.
The first 8MB contain the ME. So if you want to, read it, run me_cleaner
on it or whatever and flash it back. You will never need it for updating
coreboot as long as the BIOS is less than 4MB, which it easily is, say,
when you have only seaBIOS as your payload.
The wiki also contains an image file which is useful when you want to
to flash from a running system in software, using flashrom. I don't
doing that though. I can't say why, but my X230 died after flashing a
from a running Debian with flashrom. I couldn't bring it back to life
saved vendor bios image.
On 09/25/2017 01:21 PM, BogDan Vatra wrote:
> I'd like to upgrade my CPUs (I have 2 x Opteron 6276) and I'm now
> sure which one should I choose? Will I see a difference? Does the
> upgrade worth?
6386SE IMO, get the best.
It is worth it although it needs microcode updates for secure operations.
6287SE is the best x86_64 CPU that doesn't, it is slightly slower and
lacks the slightly higher memory speed - with that you will also see
better peformance (see cpubenchmark)
Btw no need to buy a brand new one get a used as CPU life is 20+ years.
You'll end up spending a decent chunk of change on dual 6386SE to the
point where I would advise saving up for TALOS 2 (way better performance
and upgradability) - unless you want x86 6386 to the play latest games
First, please just send plain text messages to mailing lists.
Am Montag, den 25.09.2017, 19:36 -0700 schrieb shaunak saha:
> I started seeing this issue today and was unable to fetch commits from
> coreboot server.
Please also provide the output of `LANG=C git fetch -vv origin`.
> Any solution to this problem? Do i need to check anything
> on my local ssh configs?
If you do not want to “re-clone”, then do the following as a workaround
to get the problematic commit crashing the server.
$ git clone https://review.coreboot.org/coreboot.git /tmp/coreboot
$ cd /your/problematic/coreboot/tree
$ git remote add local-rep /tmp/coreboot
$ git fetch local-rep
$ git remote delete local-rep
No everything should work again.
Am Montag, den 25.09.2017, 20:37 -0400 schrieb One7two99 via coreboot:
> -------- Original Message --------
> Subject: Re: [coreboot] Coreboot+SeaBios Boot speed: ~12sec till Grub Boot Screen
> Local Time: 25 September 2017 9:17 AM
> From: paulepanter(a)users.sourceforge.net
> > > First, please just sent plain text messages to mailing lists.
> ok, I'll try
Your reply still contained an HTML part. :(
> > > 1. Your coreboot configuration (`.config`).
> See attached.
> > > 2. The output of `build/cbfstool build/coreboot.rom print`.
> ./coreboot/build/cbfstool ./coreboot/build/coreboot.rom print
> Name Offset Type Size
> cbfs master header 0x0 cbfs header 32
> fallback/romstage 0x80 stage 81604
> config 0x13fc0 raw 641
> revision 0x14280 raw 570
> cmos.default 0x14500 cmos_default 256
> cmos_layout.bin 0x14640 cmos_layout 1804
> fallback/dsdt.aml 0x14dc0 raw 13643
> payload_config 0x18380 raw 1611
> payload_revision 0x18a40 raw 237
> etc/ps2-keyboard-spinup 0x18b80 raw 8
> (empty) 0x18bc0 null 29400
> mrc.cache 0x1fec0 mrc_cache 65536
> fallback/ramstage 0x2ff00 stage 79642
> pci8086,0166.rom 0x43680 optionrom 65536
> img/coreinfo 0x53700 payload 1150904
> fallback/payload 0x16c700 payload 67051
> (empty) 0x17cd40 null 2631064
> bootblock 0x3ff300 bootblock 3000
> > > 3. Build the utility cbmem with `make -C util/cbmem`.
> ok, done.
> > > 4. The output of `./util/cbmem/cbmem -c`.
> > > 5. The output of `./util/cbmem/cbmem -t`.
> both commands fail with "Failed to gain memory access: Permission denied"
I assume, you ran this with administrator privileges. But, newer Linux
kernels forbid access to that region.
In recent Linux kernels, there is a module for that.
`sudo modprobe memconsole_coreboot` should load it, and then the logs
should be available under `/sys/firmware/log`.
If you don’t have that, please pass the parameter `iomem=relaxed` to
the Linux kernel. For example, by pressing `e` in the GRUB menu.
Dear coreboot administrators,
Currently, I am unable to fetch the newest commits/objects(?) from the
coreboot git server.
$ LANG=C git fetch -vv origin
got ack 3 dee643a360ad75787f2982a013c62a4d49352121
got ack 3 a1de1a0810892c3c3a22ed6e2868fbef3bde8134
got ack 3 6a720e16e7e966b034c462242ccdf99e371a1ad7
got ack 3 5d5fb1402be06cacc45d4785201b719e8c3501d1
got ack 3 eb9b2c8105642ba99c34bd727e26483ffc6a0b57
got ack 3 9e882dfff180a75c28a01c49d80e27f545bddb3a
got ack 3 26ee056a55ee835a9c3bfc8b18854cb121e9371c
got ack 3 27c8b82d09083e1733bcd60bb42fc52693615ce8
got ack 3 fec58518a57f67e6e1186a573503ccaec7bcf8e6
got ack 3 4d4286faa0b5e134c71c65e0e3a3a7480ca0d79d
got ack 3 907a0831fb4ac4dc491656d68191274411c65944
got ack 3 30796a481fb752d63bb9b2f939595a29cb18c823
got ack 3 bdcf664a03ef6a4a17b1b367c9ab2fbf34aea244
got ack 3 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
got ack 4 91ec3f1264a85aa57715e059276d96bfbc178c80
got ack (4) ccbaabe5cf6b7eaa20fc323858680a404383537b
got ack (1) 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
fatal: internal server error
remote: internal server error
fatal: protocol error: bad pack header
Aaron reported the same problem in the IRC channel some days ago, and I
remember having this problem some months ago too.
Could you please take a look on the server?
First, please just sent plain text messages to mailing lists.
Am Sonntag, den 24.09.2017, 17:32 -0400 schrieb One7two99 via coreboot:
> Booting to my Grub Selection screen takes ~12sec on my X230, loosing lots of second from pressing the Power Button to the "Hit Escape Key" message from SeaBios.
> Are there any options to accelerate this and what are you Booting times to the Grub OS selection screen?
Unfortunately, you do not provide any logs, making it hard to see where
it fails. So, please reply with the following information.
1. Your coreboot configuration (`.config`).
2. The output of `build/cbfstool build/coreboot.rom print`.
3. Build the utility cbmem with `make -C util/cbmem`.
4. The output of `./util/cbmem/cbmem -c`.
5. The output of `./util/cbmem/cbmem -t`.