User:Grimler/exynos5420-peach-pit-u-boot-hacking-WIP
U-BOOT hacking
Reading out SPI flash content
To read SPI flash with a bus pirate, connect with a SOIC8 clip and run something like:
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -c W25Q32BW/W25Q32CW/W25Q32DW -r winbond_spi_flash.bin
where winbond_spi_flash.bin is name out outputted file. Make a backup (or preferably many!) of it.
 |
TODO: give instructions for reading on device |
Running dump_fmap on file shows where the different partitions are:
fmap_signature __FMAP__ fmap_version: 1.0 fmap_base: 0x0 fmap_size: 0x00400000 (4194304) fmap_name: FMAP fmap_nareas: 28 area: 1 area_offset: 0x001af000 area_size: 0x00051000 (331776) area_name: RO_UNUSED area: 2 area_offset: 0x00000000 area_size: 0x00200000 (2097152) area_name: WP_RO area: 3 area_offset: 0x00000000 area_size: 0x0019f000 (1699840) area_name: RO_SECTION area: 4 area_offset: 0x00000000 area_size: 0x00002000 (8192) area_name: BL1 PRE_BOOT area: 5 area_offset: 0x00002000 area_size: 0x00008000 (32768) area_name: BL2 SPL area: 6 area_offset: 0x0000a000 area_size: 0x000a0000 (655360) area_name: U_BOOT area: 7 area_offset: 0x000aa000 area_size: 0x0000f000 (61440) area_name: RO_ECRO area: 8 area_offset: 0x000b9000 area_size: 0x0000f000 (61440) area_name: RO_ECRW area: 9 area_offset: 0x000d0000 area_size: 0x00008000 (32768) area_name: FDTMAP area: 10 area_offset: 0x000e0000 area_size: 0x00004000 (16384) area_name: FMAP area: 11 area_offset: 0x000e4000 area_size: 0x000ef000 (978944) area_name: GBB area: 12 area_offset: 0x001d3000 area_size: 0x00010000 (65536) area_name: RO_VPD area: 13 area_offset: 0x001e3000 area_size: 0x00000100 (256) area_name: RO_FRID area: 14 area_offset: 0x00200000 area_size: 0x000f0000 (983040) area_name: RW_SECTION_A area: 15 area_offset: 0x00200000 area_size: 0x00002000 (8192) area_name: VBLOCK_A area: 16 area_offset: 0x00202000 area_size: 0x000de000 (909312) area_name: FW_MAIN_A area: 17 area_offset: 0x002e0000 area_size: 0x0000ff00 (65280) area_name: EC_RW_A area: 18 area_offset: 0x002eff00 area_size: 0x00000100 (256) area_name: RW_FWID_A area: 19 area_offset: 0x00300000 area_size: 0x000f0000 (983040) area_name: RW_SECTION_B area: 20 area_offset: 0x00300000 area_size: 0x00002000 (8192) area_name: VBLOCK_B area: 21 area_offset: 0x00302000 area_size: 0x000de000 (909312) area_name: FW_MAIN_B area: 22 area_offset: 0x003e0000 area_size: 0x0000ff00 (65280) area_name: EC_RW_B area: 23 area_offset: 0x003eff00 area_size: 0x00000100 (256) area_name: RW_FWID_B area: 24 area_offset: 0x003f0000 area_size: 0x00004000 (16384) area_name: RW_VPD area: 25 area_offset: 0x003f4000 area_size: 0x00004000 (16384) area_name: RW_SHARED area: 26 area_offset: 0x003f8000 area_size: 0x00008000 (32768) area_name: RW_PRIVATE area: 27 area_offset: 0x003f8000 area_size: 0x00004000 (16384) area_name: RW_ELOG area: 28 area_offset: 0x003fc000 area_size: 0x00004000 (16384) area_name: RW_ENVIRONMENT
Building old, original u-boot
Building a close-to-original u-boot with serial logging enabled and a bootdelay > 0 can be useful for debugging and/or other customisations.
Running strings on the original u-boot binary in SPI flash shows that it is built from commit b98ed09d1222 ("dmc: exynos5422: Add software read leveling") which can be found in chromium's u-boot repo. The branch firmware-pit-4482.B in the same repo is only two commits ahead of b98ed09d1222, and is a good option to build from. To build this old u-boot version with modern openssl versions and toolchains we need to fix some build issues, which have been conveniently been uploaded to gitlab.com/exynos5-mainline/u-boot. To get sources therefore run:
git clone https://gitlab.com/exynos5-mainline/u-boot -b peach-pit-original
cd u-boot
Chromium's u-boot also depends on their "verified boot" vboot_reference repo, so we also need to clone that one:
git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference -b firmware-pit-4482.B
Now we can build with something like:
make VBOOT_SOURCE=$(pwd)/vboot_reference O=out -j8 chromeos_peach_config
make VBOOT_SOURCE=$(pwd)/vboot_reference O=out -j8 all
if you are cross compiling you also need to point to the compiler and friends, with something like:
CC_PREFIX=/path/to/toolchain/gcc-arm-linux-gnueabihf-4-7/bin/
make VBOOT_SOURCE=$(pwd)/vboot_reference O=out CC=$CC_PREFIX/arm-linux-gnueabihf-gcc AS=$CC_PREFIX/arm-linux-gnueabihf-as LD=$CC_PREFIX/arm-linux-gnueabihf-ld AR=$CC_PREFIX/arm-linux-gnueabihf-ar OBJCOPY=$CC_PREFIX/arm-linux-gnueabihf-objcopy NM=$CC_PREFIX/arm-linux-gnueabihf-nm -j8 chromeos_peach_config
make VBOOT_SOURCE=$(pwd)/vboot_reference O=out CC=$CC_PREFIX/arm-linux-gnueabihf-gcc AS=$CC_PREFIX/arm-linux-gnueabihf-as LD=$CC_PREFIX/arm-linux-gnueabihf-ld AR=$CC_PREFIX/arm-linux-gnueabihf-ar OBJCOPY=$CC_PREFIX/arm-linux-gnueabihf-objcopy NM=$CC_PREFIX/arm-linux-gnueabihf-nm -j8 all
You will now have a u-boot binary at out/u-boot.bin, and an bl2/SPL bin at out/spl/smdk5420-spl.bin, and these can be flashed to the U_BOOT and BL2 SPL partitions of SPI flash (steps in next section). HOWEVER, device will not boot, there seem to be significant differences in google's SPL binary and the one generated by steps above.
Replacing SPL and u-boot in SPI flash
|
WARNING: be sure to backup original SPI blob before manipulating it! |
Given an SPI flash fw blob named winbond_spi_flash.bin (read out as in earlier section), and an flashmap as read by dump_fmap before we can replace SPL and u-boot parts with:
dd bs=1 seek=$((0x2000)) count=32768 conv=notrunc if=/dev/zero of=winbond_spi_flash.bin
dd bs=1 seek=$((0x2000)) conv=notrunc if=/path/to/u-boot/out/spl/smdk5420-spl.bin of=winbond_spi_flash.bin
dd bs=1 seek=$((0xa000)) count=655360 conv=notrunc if=/dev/zero of=winbond_spi_flash.bin
dd bs=1 seek=$((0xa000)) conv=notrunc if=/path/to/u-boot/out/u-boot.bin of=winbond_spi_flash.bin
and then flash it to SPI flash with something like:
flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -c W25Q32BW/W25Q32CW/W25Q32DW -w winbond_spi_flash.bin
But, again, above will brick your chromebook, requiring you to re-flash original flash blob (that you backup'ed multiple times, right?).