GitHub PushEvent at 2014-12-05 08:52:56
Repository: chromiumos-third_party-coreboot
Actor: mtk09422
Payload: {"shas":[["4f064fdca5b6c214e7a7f2751dc24e33cac2ea45","5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org","spi: support controllers with limited transfer size capabilities\n\nSome SPI controllers (like Imgtec Pistachio), have a hard limit on SPI\nread and write transactions. Limiting transfer size in the wrapper\nallows to provide the API user with unlimited transfer size\ntransactions.\n\nThe tranfer size limitation is added to the spi_slave structure, which\nis set up by the controller driver. The value of zero in this field\nmeans 'unlimited transfer size'. It will work with existion drivers,\nas they all either keep structures in the bss segment, or initialize\nthem to all zeros.\n\nThis patch addresses the problem for reads only, as coreboot is not\nexpected to require to write long chunks into SPI devices.\n\nBRANCH=none\nBUG=chrome-os-partner:32441, chrome-os-partner:31438\nTEST=set transfer size limit to artificially low value (4K) and\n     observed proper operation on both Pistachio and ipq8086: both\n     Storm and Urara booted through romstage and ramstage.\n\nChange-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b\nSigned-off-by: Vadim Bendebury <vbendeb@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/232239\nReviewed-by: Aaron Durbin <adurbin@chromium.org>\nReviewed-by: David Hendricks <dhendrix@chromium.org>","Vadim Bendebury",true],["e707c67c69599274b890d0686522880aa2e16d71","4d12f06cff3725783b352157673a720bc67c4afe@chromium.org","CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstool\n\nSome projects (like ChromeOS) put more content than described by CBFS\nonto their image. For top-aligned images (read: x86), this has\ntraditionally been achieved with a CBFS_SIZE Kconfig (which denotes the\narea actually managed by CBFS, as opposed to ROM_SIZE) that is used to\ncalculate the CBFS entry start offset. On bottom-aligned boards, many\ndefine a fake (smaller) ROM_SIZE for only the CBFS part, which is not\nconsistently done and can be an issue because ROM_SIZE is expected to be\na power of two.\n\nThis patch changes all non-x86 boards to describe their actual\n(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a\nmainboard Kconfig select (which is the correct place to declare\nunchangeable physical properties of the board). It also changes the\ncbfstool create invocation to use CBFS_SIZE as the -s parameter for\nthose architectures, which defaults to ROM_SIZE but gets overridden for\nspecial use cases like ChromeOS. This has the advantage that cbfstool\nhas a consistent idea of where the area it is responsible for ends,\nwhich offers better bounds-checking and is needed for a subsequent fix.\n\nAlso change the FMAP offset to default to right behind the (now\nconsistently known) CBFS region for non-x86 boards, which has emerged as\na de-facto standard on those architectures and allows us to reduce the\namount of custom configuration. In the future, the nightmare that is\nChromeOS's image build system could be redesigned to enforce this\nautomatically, and also confirm that it doesn't overwrite any space used\nby CBFS (which is now consistently defined as the file size of\ncoreboot.rom on non-x86).\n\nCQ-DEPEND=CL:231576,CL:231475\nBRANCH=None\nBUG=chromium:422501\nTEST=Built and booted on Veyron_Pinky.\n\nChange-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc\nSigned-off-by: Julius Werner <jwerner@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/229974\nReviewed-by: Aaron Durbin <adurbin@chromium.org>","Julius Werner",true],["92292c69ced6996f1fa37b3411327f17aaa5869f","4d12f06cff3725783b352157673a720bc67c4afe@chromium.org","configs: Align ChromeOS board configs to CBFS_SIZE change\n\nThis patch fixes up our board configs to conform to the new relationship\nbetween CBFS_SIZE and ROM_SIZE, and to remove the FLASHMAP_OFFSET which\nnow has a useful default.\n\nBRANCH=None\nBUG=None\nTEST=Tested with other patches.\n\nChange-Id: I4781df455ee15ddc91b51d2c42cdeedd60089027\nSigned-off-by: Julius Werner <jwerner@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/231576\nReviewed-by: Aaron Durbin <adurbin@chromium.org>","Julius Werner",true],["e9879c0fbd57f105254c54bacb3e592acdcad35c","4d12f06cff3725783b352157673a720bc67c4afe@chromium.org","CBFS: Automate ROM image layout and remove hardcoded offsets\n\nNon-x86 boards currently need to hardcode the position of their CBFS\nmaster header in a Kconfig. This is very brittle because it is usually\nput in between the bootblock and the first CBFS entry, without any\nchecks to guarantee that it won't overlap either of those. It is not fun\nto debug random failures that move and disappear with tiny alignment\nchanges because someone decided to write \"ORBC1112\" over some part of\nyour data section (in a way that is not visible in the symbolized .elf\nbinaries, only in the final image). This patch seeks to prevent those\nissues and reduce the need for manual configuration by making the image\nlayout a completely automated part of cbfstool.\n\nSince automated placement of the CBFS header means we can no longer\nhardcode its position into coreboot, this patch takes the existing x86\nsolution of placing a pointer to the header at the very end of the\nCBFS-managed section of the ROM and generalizes it to all architectures.\nThis is now even possible with the read-only/read-write split in\nChromeOS, since coreboot knows how large that section is from the\nCBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be\nchanged on systems that place other data next to coreboot/CBFS in ROM).\n\nAlso adds a feature to cbfstool that makes the -B (bootblock file name)\nargument on image creation optional, since we have recently found valid\nuse cases for CBFS images that are not the first boot medium of the\ndevice (instead opened by an earlier bootloader that can already\ninterpret CBFS) and therefore don't really need a bootblock.\n\nBRANCH=None\nBUG=None\nTEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.\n\nChange-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af\nSigned-off-by: Julius Werner <jwerner@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/229975","Julius Werner",true],["4be8900ca35e9e7057a3a3842028a2968ef5a23b","4d12f06cff3725783b352157673a720bc67c4afe@chromium.org","libpayload: cbfs: Remove absolute pointer special case from ram_media\n\nThis patch changes the ram_media CBFS backend implementation to no\nlonger detect an absolute address that is inside the \"memory region\"\nused to back the CBFS image (which on x86 is really just the\nmemory-mapped flash due to a depthcharge implementation detail). This\nwas (as far as I know only) used to support the ugly CBFS header pointer\nsituation with SeaBIOS, which is now resolved. It is a very dangerous\nfeature, since it's perfectly possible for a negative offset relative to\nthe end of the image to overlap that region. We only get lucky that in\nour existing use cases the embedded CBFS is further away from the end of\nthe ROM than it's own size... if we instead had a 3MB image from\n0xfffd0000 to 0xffff0000, then we might want to pass in an address like\n0xfffe8000 (interpreted as a relative offset from the end) to refer to\nthe absolute address 0xfffd8000, but this feature would prevent that\nsince it fits inside the window when interpreted absolutely. (Also, it\nis unlikely but possible that a non-memory-mapped architecture which\nstarts DRAM at 0x0 may put its bounce buffer within the first few\nmegabyte of the address space, so that a relative offset from the start\nof the image could be interpreted as an absolute offset inside the\nbuffer.\n\nCQ-DEPEND=CL:229962\nBRANCH=None\nBUG=None\nTEST=Built and booted on Falco and Nyan_Blaze, confirmed that legacy\nmode still works as well as before.\n\nChange-Id: I0c9149d725adeecef2520342b307ce7ea52990c1\nSigned-off-by: Julius Werner <jwerner@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/229976\nReviewed-by: Aaron Durbin <adurbin@chromium.org>\nReviewed-by: Stefan Reinauer <reinauer@chromium.org>","Julius Werner",true],["94008340bc5eaf19d286b3feaa4091e5c5e285aa","5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org","util: ipq8064: utility to create uber-SBL\n\nWith the Storm image layout reworked, the very first blob read out of\nNOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation\nof three binaries: one to run on RPM, another one to run on AP, and\nthe third one - the actual coreboot bootblock.\n\nThis layout allows to greatly reduce the size and complexity of the\ntwo first blobs, as they do not need to include the SPI driver.\n\nThe first binary in the input file list starts with the combined\nheader, describing the rest of the blob. This utility copies the first\ninput file into output, updating the combined header with the total\nsize of the concatenated binaries.\n\nThe second and third binaries in the combined image are required to be\naligned at 256 byte offset in the file as calculated off the end of\nthe combined header. The new utility allows to concatenate two or\nthree files, always expecting the first file to be prepended by the\ncombined header.\n\nFor further reference below is the utility's help message:\n\n  mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock]\n\n  Concatenates up to three mbn files: two SBLs and a coreboot bootblock\n    -h This message\n    -v verbose\n    -o Output file name, (default: sbl-ro.mbn)\n\nBRANCH=none\nBUG=chrome-os-partner:34161\nTEST=run the new utility and compared the result with the output of\n     the vendor provided tool. The output files are exactly the same.\n\nChange-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5\nSigned-off-by: Vadim Bendebury <vbendeb@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/232047\nReviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>\nReviewed-by: David Hendricks <dhendrix@chromium.org>","Vadim Bendebury",true],["a126a62f65a568d62fe35bdcf27eaec38fd1a997","5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org","ipq8064: use the new utility to build bootblock\n\nThe first blob in the Storm bootimage is a concatenation of the\nUber-sbl produced by the qca-firmware ebuild and the coreboot\nbootblock.\n\nThe new tool is used to add the bootblock to uber-sbl and update the\nsize values in the combined header.\n\nBRANCH=storm\nBUG=chrome-os-partner:34161\nTEST=no execution tests yet, the build succeeds.\n\nChange-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38\nSigned-off-by: Vadim Bendebury <vbendeb@chromium.org>\nReviewed-on: https://chromium-review.googlesource.com/232310\nReviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>\nReviewed-by: Trevor Bourget <tbourget@codeaurora.org>\nReviewed-by: David Hendricks <dhendrix@chromium.org>","Vadim Bendebury",true],["51edf4205918de079d5283b6c77370b1eb8c82be","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","Add initial Google/Llama board\n\nChange-Id: Ib110519be4669310545a5b182ed4e958a2c4e7ba\n\nConflicts:\n\tpayloads/libpayload/Config.in\n\tsrc/lib/cbfs.c\n\tsrc/mainboard/google/Kconfig\n\tsrc/soc/Kconfig","Yidi Lin",true],["75e5d08c4b57fa731f7a129f635200fd55a90732","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","Remove moose board\n\nChange-Id: I916d6b9ac3a73b2b15d4a0cc4dcb78cab65d9fde","Yidi Lin",true],["7da0eb3bf04b90d1ef81bc0e1350d69cb85d9817","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","Revise for supporting SMP.","Yidi Lin",true],["93fe60e95dff5e28cd40e8c411254af92b80cd3e","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","Amend the I2C driver to support multiple bytes (>8) transaction for TPM","Yidi Lin",true],["6522a2fd7a7683f51dad2d470fae858a006a86d9","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","mt8135: switch to stopwatch API\n\nChange-Id: Ia3740e99240a429b5199b61f82af4b01b891cc36","Yidi Lin",true],["4459b8b96bf38e8c30c514ff670fe6da078cc0f2","0c4001101cc93bbb05bfafdf6c0c714363bf8c17@mediatek.com","Fix the build warning by newer chromium toolchain.\n\nChange-Id: Ib0aed7b9f7a2b44725c36fd8f781659b35942cea","cc.ma",true],["2ed6cf35cece0bd0a7a08c81a0eb0bfe876d2f95","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","llama: Add memlayout.ld\n\nChange-Id: I0f81df5785fbaaa202b1855175d3445d909c5ed9","Yidi Lin",true],["759aa3e9810cc036d9f211261aad19ed7cdac666","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","llama: Add UART support\n\nChange-Id: I614971c139c7c2972452a3526ffd2ba616b63781","Yidi Lin",true],["38f4e6c6bcc787dc533458af251662d15e76d242","4823cef9c77b3997aeafd408a373a4ac2a720f54@mediatek.com","mt8135: Fixed memory layout. Defined SRAM_M4U region that contains\nBOOTBLOCK.\n\nChange-Id: I71856e1af7fb3d8e908ecfa74fe79290a010f81b","Yidi Lin",true]],"size":16,"ref":"refs/heads/tot-dev","head":"38f4e6c6bcc787dc533458af251662d15e76d242"}