Okay, so, why would you want to do this? Well, in a nutshell, so your Chromebook pretty much behaves like a normal laptop i.e. no secure boot, will boot from any USB key, no more signing kernels and dd’ing them to obscure partitions, etc, etc. Before you start: It’s important to note this comes without any warranty, express or implied. If something goes wrong you will end up with a bricked Chromebook. If that happens you can purchase a Bus Pirate, Bus Pirate probe cable, and Pomona 5250 SOIC clip and get unbricking, as per my previous post. This will also make ChromeOS unbootable, so if you want to use ChromeOS at all, then don’t do this. The impatient and ill-resourced among you can scroll to the end for instructions on how to download and flash my Coreboot build, which again comes without any warranty and could bring hell and damnation upon your souls. There is now a patch which allows all 4 GB of RAM to be recognised, but it takes 5 seconds to reach the SeaBIOS prompt on a cold boot. First of all you need to make sure the Chromebook is in developer mode as per http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge and you also need to disable the BIOS write protect jumper which this picture shows you. For reference, I carefully placed a small watch screwdriver in between the 2 pins to make a circuit. Worked for me anyway. ;) On your Chromebook, make a copy of your existing ROM with
sudo flashrom -r bios.bin
Copy it to USB or use SFTP to get it onto your other PC/Laptop. This is extremely important because you may need something to recover from later. Now we have to download the Coreboot sourcecode onto a laptop with a suitable Linux distro, using Git. Obviously we need Git installed, as well as GCC, Ncurses development, and iasl. From your home directory on this machine.
git clone http://review.coreboot.org/p/coreboot
Then go into menuconfig.
make menuconfig
Now we need to check and uncheck some options. I don’t list categories here for brevity. Just go into each section to find the options mentioned.
- Uncheck Compress ramstage with LZMA
- Uncheck Include the coreboot .config file into the ROM image
- Check Allow use of binary-only repository
- Change Mainboard Vendor to Samsung, which should automatically change the mainboard to “Lumpy”
- Check Mark graphics memory as write-combining.
- Check Enable VMX for virtualization
- Check Allow for caching system ROM.
- Check Add a System Agent binary
- Check Add a VGA BIOS image.
- Change the binary path to 3rdparty/mainboard/$(MAINBOARDDIR)/snm_2130_coreboot.bin
- Uncheck Serial port console output
- Check Use onboard VGA as primary video device
- Change SeaBIOS version to “master”
- Uncheck Use LZMA compression for payloads
Install iasl
Next we need to make a trivial change to the SeaBIOS source to change the bootmenu key from F12 (because Chromebook’s don’t have F12) From the coreboot directory vim build/seabios/src/boot.c and change the following section like so:
int menukey = romfile_loadint("etc/boot-menu-key", 0x86); printf("%s", bootmsg ?: "\nPress F12 for boot menu.\n\n"); free(bootmsg);
to
int menukey = romfile_loadint("etc/boot-menu-key", 0x44); printf("%s", bootmsg ?: "\nPress F10 for boot menu.\n\n"); free(bootmsg);
We change the “F12” to “F10” and “0x86” to “0x44”.
make
The cbfstool printout at the end should look something like this:
Name Offset Type Size cmos_layout.bin 0x400000 cmos_layout 1120 pci8086,0106.rom 0x4004c0 optionrom 65536 cpu_microcode_blob.bin 0x410500 microcode 20544 fallback/romstage 0x4155c0 stage 28660 fallback/coreboot_ram 0x41c600 stage 287464 fallback/payload 0x462940 payload 106916 (empty) 0x47cb40 null 3159128 mrc.cache 0x77ffc0 (unknown) 65536 (empty) 0x790000 null 65432 mrc.bin 0x79ffc0 (unknown) 195732 (empty) 0x7cfcc0 null 49880 spd.bin 0x7dbfc0 (unknown) 1536 (empty) 0x7dc600 null 144216
Copy the coreboot.rom file in build to your Chromebook and write the file to your ROM!
sudo flashrom -w coreboot.rom
Alternatively, as mentioned at the beginning of the post, you can download a prebuilt coreboot from my website, and flash it without much bother. See https://johnlewis.ie/custom-chromebook-firmware/rom-download/
Many thanks to Ron Minnich, Aaron Durbin, Stefan Reinauer and Kyösti Mälkki, on the Coreboot mailing list.
Hey…I am sorry I was off for 3 days …
So I used this pre-build firmware http://johnlewis.ie/coreboot-lumpy-grub2-good-23102013.rom for my Samsung series 3 and I’ve got this error
Error: Image size doesn’t match
FAILED
So yea I know this pre-build firmware is for series 5 which their processors are inter, but here is my question…If I downloaded your source code and compiled for Arm…Will it work for the series 3 ???
Thank you…
Regards.
Can we just clear this up once and far all. Which model do you have? Is it the Samsung Series 3 ARM Chromebook *or* the Samsung Series 3 Chromebox?
I think somebody in the community group managed to compile a ROM for Lumpy which is confirmed working. Take a look through there, it was fairly recent.
Hello John,
Actually that raises a valid point, would you have an idea if trying to build coreboot for stumpy (Samsung Series 3 Chromebox) would be much different then this process? According to the SeaBios site, it is supported and also supported to use flashrom to install. Just can’t find a valid binary, so using your example to see if I can build one..
Cheers,
Raj
Actually there is now a ROM for the Samsung Chromebox (Celeron). The script on the ROM download page will flash it for you.
John, you’re a star.. perfect… just need to disable the write protection and I’m gonna give it a shot.
Have you managed to test installing Windows with it?
Actually, while that is awesome, just realised it won’t work for me.. I haven’t got a Celeron based Stumpy, however I do have a Core i5 based on.. (Google I/O edition).
Well, if you can tell me the PCI id’s of the graphics card, I’ll build one, and add it to the script. “lspci -nv” is your friend.
John, the VGA controller has a kernel driver in use: i915 (if that’s what you’re looking for?)
00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller])
Subsystem: 8086:0126
Flags: bus master, fast devsel, latency 0, IRC 43
Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 2000 [size=64]
Expansion ROM at [disabled]
Capabilities:
Kernel driver in use: i915
Okay, that’s enough to make a ROM with. In fact, I already have one for you to try.
https://johnlewis.ie/coreboot-stumpy-youaintgettingit.rom
md5sum feb6975a7b3525b66e07f983569d19f0
Hey John,
Not sure if joke with name of rom, but thanks for your help so far.
It is, but it’s not directed at you. :)
I take it you haven’t tried it yet?
Gotcha, haven’t tried it yet, as jumper I foiled was the wrong one, so taking Chromebox apart to see if I can get the damn thing to be writeable.. have downloaded and verified the md5sum tho, and that all checks out.
It’s one of two jumpers in the most inconvenient spot (info on Chromium site is wrong, not to mention the Stumpy doesn’t have a battery), however on the board, there are two jumpers on the top side.
Gotta love lack of time, so sorry I can’t test it as quickly.. should have it done soon.
No worries.
Hmm, flashrom is still telling me this board is still disabled with it’s writes, and reading the flash gets a transaction error? SPI Configuration Lockdown activated.. bugger.
If you look at this: https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge/stumpy-bottom-cards.jpg
The two jumpers I’ve tried are on the left top side, near the 4 USB sockets..
Currently running Chrbuntu and got flashrom with a apt-get install flashrom (noticed it doesn’t have the –wp-disable flag supported).
Any ideas? I’ll keep trying to hack away at it.
What does crossystem say?
You could also post a pic of your board? I’ve seen a number of models at this stage, so I know the kind of thing to look for.
John, It’s exactly the same as the stumpy shown at the bottom of this site: http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge
Hi John,
I’ve flashed your test build (coreboot-stumpy-youaintgettingit.rom).
It tries to boot Chrome OS from the mSATA SSD and fails. That was expected, but I’m unable to boot from USB as well. The boot menu shows both the internal SSD an the USB thumb drive. After selecting “2” (USB) it gets stuck at “Booting from Hard Disk”.
Removing the write protect jumper doesn’t help.
As next step I plan to replace the SDD with one that has Debian or Ubuntu preinstalled.
Do you have any further tips?
Kind regards,
Christian
Have you managed to boot the USB stick on another machine?
Yes, that’s a good next move. Possible problem with the SeaBIOS I have in there.
I think the version of SeaBIOS in that build has a problem with external keyboards. I’ve updated it to 1.7.5. I’ve also added a “links” file which will automatically cope with the different PCI id’s that Stumpy has for the graphics card i.e. 8086:0106 and 8086:0126 so you can flash it using the script once you get your distro on there.
Today I was able to boot my i5 Stumpy box by putting in a preinstalled SSD. Immediately after that I’ve tried your new script, but it has failed.
After some debugging I’ve found a solution:
model=`dmidecode | grep -m1 "Product Name:" | awk '{print $3}'`
The -m1 is necessary, because grep finds “Product Name: Stumpy” twice.
Finally all is working fine, including Standby and USB-Boot, even using unetbootin created sticks.
Thank you very much John. A PayPal Donation will follow shortly.
Thank you very much for that, and your amazingly generous donation. I’ll update the script in line with your fix.
Hi,
Is it now possible to flash a chromebox serie 3 with a core i5 from google I/O ?
Thank you in advance
Yes.
I guess it’s the right place to post ,
I realized that i must disable write protect by closing a circuit on my board , I’ve opened it , and everywhere it says the jumper on stumpy is between the memory and the battery , which clearly it doesn’t have battery .
so i’m a bit puzzled , the jumper on series 5 550 looks alot like the speaker connector of stumpy :D lol.
probably Christian Reischl , can put me in the right path ?
any help would be appreciated .
You can see the jumper labelled in this photo. I used a small watch screw-driver wedged between the pins (careful not to bend or break them). HTH.
https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge/lumpy-internals.jpg?attachauth=ANoY7cp0kieC9BB3au1ddDA1h7j2G1JgBCfYOnNYNfdQW4_9tBvIRsFPho5W1c5KwVUY_MPjhYe3MSlT9PHLR1NKBNGKgzx6r3_qQdLg6FGqxnxoiBzAUYmL-I2y9H9uVzbJVu81k9yBeE9Sx5vPzMu3LIL0a6wiXLm5IhSWR9-CgjSnG0VYRMUVYdTB6KhruShqj4QewDHFMUEUobVHxAFbfTmS__3hpNR4QyTE-O1Rf-zlx1k7yAL0RQBb4LVH4B_2gg-4TQUZbL_NkNNP_CYRu5n0N6diAtIkAlBumoyshj_0f7ZAnJVX1EXCbHqt8VTvYFHRc8mf&attredirects=0
I am confused regarding the two pins. I have seen the lumpy board picture many times and I know where the write protect jumper is. But I can’t seem to disable the write protect. The red box in the lumpy board picture just outlines a general area around the white cube. But I am not sure which two pins to short. If you open the picture,
1) Just left of the white cube, there are two long legs coming out. One the left edge of the white cube these two long legs occupy the north-most position. I will call these two pins 1 & 2
2) A little south of 1 & 2, there are two more pins. These are further away from the left edge of the cube. I will call them 3 & 4
3) And at the bottom-left corner of the white cube there are two dots. I will call them 5 & 6.
I have shorted 1 & 2 (didn’t work) and then 3 & 4 (didn’t work either).
When I run the command $crosssystem it shows
wpsw_cur = 1
which means write-protect switch’s current position is 1 (ON).
Can someone help on how to short the jumper? Which two pins are correct in terms of 1,2,3,4,5,6 described above?
It’s the two pins which are in the white cube. I used a small watch screwdriver to gently wedge between the pins and provide the circuit. I don’t know what you mean about other pins because AFAICS those are the only two pins around. Are you looking at this picture?
https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge/lumpy-internals.jpg?attachauth=ANoY7cr-S_r1lP-fSy-6uPq_MmCG0IGb9iWy-8Hi3n_XTcQp6wQhvpGPQ6xHRYFQZm69kHnLi4Ct0opeL1spXsvlMvCtCzBNL76c6p2PkDNe3RgKSILnidK6KCS-_Ici5c_xGCG9-t2SY9Pg65J4uSeAhq3RSLrjTQq5ip3B9XxyVNM1gDj4wji9rkVGvNSedbhnw0sLR2eW3CPOxomIanLspdieIW9vgE76CBaVHKFPzETr1btAMUO-OX5Fo80i3LfT4L-u70rNxlAPAB7QQpMB3OrDI3gyKcX_8gKKm-aSD-mJ44V2s5C9ROCD0iGKtiw3qGiy-G-r&attredirects=0
Hi thanks for the reply. I finally got it working. Yeah I later realized two very important things (maybe they are obvious but took me a while to figure out).
1) The pins are “inside” the white cube (obstructed from view).
2) Also very very important for n00bs like me …. you have to execute flashrom “while” the screw-driver is wedged and the circuit is shorted. It wont work if you short it and then release it and then go back to console/terminal.
*** STOP Reading if you will use prebuilt coreboot from John **
(If you are building your own ROM)
Since this is 2015 a few things have changed slightly in coreboot compilation.
1) “Mark Graphics memory as write-combine” — is now automatically assumed and they decided not to make it explicit in menuconfig. You will no longer find it.
2) ‘Cache system ROM’ option was reportedly causing more trouble than help. Due to other speed improvements and due to the buggy nature of this option, they removed it from menuconfig. You will no longer find it.
3) It is also recommended to do a “make crossgcc” before doing “make”. The crossgcc target generates a dedicated toolchain for coreboot compilation and avoids using the toolchain in your Linux distro. This is because, various Linux distros patch their included toolchain in peculiar ways which is known to cause some issues in coreboot compilation. As a result “make” will quit with an error if you don’t do “make crossgcc” first. However if you are 100% confident with your local toolchain, you can set the env variable CONFIG_ANY_TOOLCHAIN = ‘y’ and it will work. “make crossgcc” takes a long time and the arm toolchain generation (absolutely not necessary for Samsung 550) is broken. But you can make it work by simply excluding the arm target in makefile.
Sorry about rambling but wanted to document these for any future adventurer. Overall, thanks John for the detailed write-up. I didn’t have a laptop and am short on cash. I got the Samsung 550 for $99 from ebay, upgraded the SSD to 64G for about $20 (also from ebay) and installed Xubuntu. Seriously it feels like an expensive Macbook Air.
Well, I don’t know if there’s much point in documenting the changes, as the information will become stale quite quickly, but I’ll leave it here on the off chance some of it remains relevant.
Yes, the 550 was the quickest Chromebook (outside of the prohibitively expensive Pixel) before the Haswell’s made it onto the scene. I was very happy with it. For that kind of money, it’s a steal, as it’s pretty good quality.
Hi John,
I saw that you have custom built firmware for Peppy (Acer c720p) . I am trying to do the same, but all I end up with is a bricked system. Can you share the core boot menuconfig options for Peppy ?
In case it helps , I have detailed the steps I did in the google group ( https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-os-dev/coreboot$20peppy/chromium-os-dev/bAGKbJ4H0uw/2h-q9K-GJkoJ)
Cheers,
– Arpita
The .config is inside the ROM’s, you can extract it with cbfstool. HTH.
Thanks a bunch ! :)
I could extract the config from the original BIOS , but still land up with a bricked system. Is there a way in core boot to check that the config file loaded during menuconfig is the one actually used during make ?
It is the one used during make. It’s inserted automatically by the coreboot make system. There’s probably something wrong with one of the binaries you’re using. Either that or you’re trying to build for Baytrail which very few if any have been able to do successfully.
@Arpita
Do you build on x86_64 system? If so, try to use clean x86 32 bit system. I had the same issues when building on 64bit host, nothing worked, always got black screen. Now I use clean ubuntu 14.04 32 bit host for build and the same .config is booting now .
I used the latest coreboot git (420b0f6), its working. Just be sure to use the coreboot cross compiler (do ‘make crossgcc’ after doing the ‘make menuconfig’). Also check if you have the correct VGA id (pci8086,0a06 for peppy) or a appropriate “links” file in your cbfs.
samsumg NP300E5C does not boot from the hard drive that I make aga the boot from the hard drive
I can update the bios of the PC with the 5 Series describing here SAMSUNG SERIES 5550?
samsumg NP300E5C no hace boot desde el disco duro que debo hacer para que aga el boot desde el disco duro
puedo actualizar el bios de este pc con el de la serie 5 que describe aqui SAMSUNG SERIES 5 550 ?
Not unless you want a brick, you won’t …
I am using on of your prebuilt ROMs
coreboot-lumpy-seabios-good-22102013.rom to be exact
and when I md5sum it, I get ‘232ee4932d30697a6d069345cb40f78a’
and that is not the one that you have above, so is this wrong?
I don’t believe the download is corrupted
Thanks
Well, it’s a different file, so it will have a different checksum. If you look in the same location you downloaded the file for “lumpy.md5” you’ll see the md5 for the file your using in amongst the checksums for all the others.
Thanks for the quick reply, I went ahead and flashed it but got a ‘FAILED’ message. so I re-flashed my backup just to be safe. What am I doing wrong for me to get that failed message?
Nothing, as long as it’s the “spi_block_erase_20 failed during command execution at address 0x0|Verifying flash… VERIFY FAILED at 0x00000062! Expected=0xff, Read=0x0b, failed byte count from 0x00000000-0x007fffff: 0x4|Your flash chip is in an unknown state.|DO NOT REBOOT OR POWEROFF!|FAILED” error. That’s part of the firmware descriptor which can’t be overwritten.
How do you know that ROM is any good, BTW?
Well I do have that exact error. But it is your ROM so I trusted it, should I not?
No, you shouldn’t. Just because it’s up on the server, doesn’t necessarily mean it works. Unless you have a very good reason to (like somebody else told you that a particular ROM has a feature the latest ROM doesn’t) you shouldn’t go installing ROM’s willy nilly. The script is there to make flashing as safe as possible, and take human err/guesswork out of the equation.