{"push_id":918237277,"size":11,"distinct_size":11,"ref":"refs/heads/rneri/wip/pxe","head":"035b1410e4640636724141c5ab983055d74228ca","before":"5f6d1ef53e28ef7fae6fe8567c3e33ed586f4e17","commits":[{"sha":"63187740b5302029d66490f7fa52319ca98ae0a8","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"luv-efi: decouple BITS installation from efi_populate\n\nGiven the extent of the steps needed to install BITS, it makes sense to create\na separate function. This helps to improve readability as it is more clear\nthat it is only required for certain CPU architectures. Furthermore, not all\nall the users of luv-efi need efi_populate but do need to have BITS installed\n(e.g., luv-pxe-image).\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/63187740b5302029d66490f7fa52319ca98ae0a8"},{"sha":"793da7d706b7884ba8c2398819855f3e9bceda47","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"bits: run more more than one job simultaneously when building\n\nMany components are built for BITS. Thus, it could benefit greatly from\nparallel builds. In regular components, oe_runmake would take care of\nadjusting the number of parallel jobs. However, the BITS calls make within\nits Makefile and oe_runmake cannot be used. Instead,\na BITS_PARALLEL_JOBS string is used. This string is then replaced with\nbitbake's PARALLEL_MAKE.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/793da7d706b7884ba8c2398819855f3e9bceda47"},{"sha":"0195dbbc8ba3aacfeef573ff81b8bc37cf526e3e","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"bits: clear log after parsing results\n\nLUV can save multiple testing results if booted multiple times. However, BITS\nreuses the same testing log file at each boot. If a LUV bootable media\nhas been used previously, the BITS log file will contain the results obtained\nin a previous boot. These results will be wrongly parsed in the LUV test\nreport. Thus, a new empty log file for BITS needs to be created once LUV is\ndone parsing it. BITS expects a file of 512kB in size.\n\nThe core-image-efi-initramfs recipe is updated with coreutils to include the\n'yes' utility to generate the empty file.\n\nReported-by: Gayatri Kammela <gayatri.kammela@intel.com>\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/0195dbbc8ba3aacfeef573ff81b8bc37cf526e3e"},{"sha":"468f4dfacb5b8277b0b3c7ec3c5fa948074c204f","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"bits: python: redirect: add support for cpio archives\n\nThe cpio archive format allows to save files sequentially in a fairly simple\nmanner. Furthemore, using a cpio archive is a convenient way of passing\nfilesystems to Linux. The purpose of adding support for cpio is to write the\nlog results into a file that can be passed as a ramdisk to Linux. The log file\ncan be examined from Linux by simply opening the file in a predetermined\nlocation; no disk mountings involved. This especially useful with netboot;\nin which there are no disk to save logs.\n\nThe support provided by this implementation is rather primitive. Given a cpio\narchive, functions are provided to determine if a given file is present in the\narchive. If found, the beginning of the file is given as an offset from the\nbeginning of the archive. The size of the file is also given to make sure that\nno writes are done beyond the boundaries of the file. This cpio support is added\nto the redirect module via a new write_logfile_cpio that takes as arguments\nthe name of the cpio archive as well as the file within the archive to which\nlogs will be written to.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/468f4dfacb5b8277b0b3c7ec3c5fa948074c204f"},{"sha":"e47d3637b75100c4a48085dbce59285aef68e28f","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"bits: save log to a cpio archive\n\nNow that support for cpio file archivers has been added, generate\na cpio file as part of install-log. This is a simple cpio archive\nthat contains the single file /home/root/bits-log.txt as well as\nits subdirectories. This a location that should be easily accessible\nfrom Linux if the cpio archive is passed as a ramdisk. As with the\noriginal bits-log.txt, the file is 512k in size.\n\nThe init module is updated to make use of this cpio archive.\n\nChanges in this patch write log in both the plain bits-log.txt and the\ncpio archive. Support for the plain bits-log.txt will be dropped\nin a subsequent patch that includes updates to the BITS LUV test\nrunner.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/e47d3637b75100c4a48085dbce59285aef68e28f"},{"sha":"76972ce2d0e18f85772f66164c9071fa355c2dab","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"luv-test-manager: add support for network boots\n\nThe test manager perform several checks and configurations under the\nassumption that it always boots from disk (i.e., identify the intended\ndisk partitions, mount them and create the directory structure).\n\nWhen booting from the network, we don't have a disk. The test manager creates\na temporary directory structure to save the test results that can be later\nsent to a remote system.\n\nTo identify that LUV has booted from the network the test manager\nlooks for the \"luvpxe\" option in the kernel command line.\n\nCc: Gayatri Kammela <gayatri.kammela@intel.com>\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/76972ce2d0e18f85772f66164c9071fa355c2dab"},{"sha":"b06f5ef66c72455e5c2a0342cf1ef070dc6ec92f","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"bits: drop support for plain bits-log.txt\n\nSupport has been added to BITS to write testing logs to a cpio archive. This is\nmore convenient as the cpio file can be simply passed as a ramdisk to Linux; no\nneed to mount any disks. This is also useful when no disks are present, such as\nwhen booting from the network. Given this new functionality, we can now drop\nsupport for testing logs in the plain bits-log.txt\n\nIn case we boot from disk, a new empty cpio archive needs to be generated\nfor subsequent reboots. This is created in a temporary directory and copied to the\nboot partition. The generation of this cpio disk requires findutils and cpio, which\nare added to the LUV ramdisk recipe.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/b06f5ef66c72455e5c2a0342cf1ef070dc6ec92f"},{"sha":"21405c59d78ca2e4c4cb91a63cbdf1ffb654876d","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"grub: core: efi: chainloader: verify and load image separetely\n\ngrub_shim_load_image can be used used to load an UEFI application when the UEFI\nLoadImage boot services is not adequate for certain reasons: when image validity\nis not verified via UEFI Secure Boot but a different method (e.g, the\nverification protcol provided by the shim boot loader). Another good use of\ngrub_shim_load_image is to load images from a memdisk. In this case UEFI\nLoadImage cannot be used as it requires a DevicePath that maps to a physical\ndisk. In such a case, the shim verification bootloader may not be present. Thus,\nthe verification and the actual load of the image need to be done separately.\n\nIf UEFI LoadImage returns with GRUB_EFI_SECURITY_VIOLATION, try to verify\nwith grub_shim_verify. If successfull, load the image.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/21405c59d78ca2e4c4cb91a63cbdf1ffb654876d"},{"sha":"2e88eafd7254cf188e6d3bd7ea4ee2f6163f063f","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"grub: core: chainloader: efi: extend EFI loader options\n\nThe EFI Loaded Image protocol interface structure described in the UEFI\nspecification contains a LoadOptions member that can be used to obtain\ndata that is relevant to the loaded image. This LoadOptions is used by\nthe grub EFI chainloader to pass command line arguments to the loaded\nimage. This functionality can be extended to contain not only a string\nof command line arguments but also other binary data that could be\nused by the chainloaded image.\n\nWhen grub chainloads another grub image (as is the case when the LUV\ngrub chainloads to the BITS grub) this mechanism can be very useful if\nboth grubs needs to share data.\n\nIn this implementation a new grub_loader_options is added. It includes\nboth the command line string and a grub_disk_dev. Adding a grub_disk_dev\ncan be useful if, for instance, the chainloaded grub needs to access a\nmemory disk owned by the chainloader.\n\nAt the chainloder grub side, functionality is added to populate the new\ngrub_loader_options. At the chainloaded grub side, this grub_loader_options\nare handled. At the moment this grub implementation only needs the\ngrub_disk_dev and this is the only option handled. The command line arguments\nare not parsed.\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/2e88eafd7254cf188e6d3bd7ea4ee2f6163f063f"},{"sha":"d80a995d2f96c242973e3c1219d7ad7f14ea1753","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"grub: core: loader: add support for memdisks\n\nThe grub EFI chainloader uses the UEFI LoadImage boot service to load an\nexecutable image. Unfortunately, this service requires a device_handle and it\ndoes not support memdisks. This limitation can be circumvented by using\ngrub_shim_load_image. This requires to rework the grub EFI chainloader to only\nuse LoadImage if it can find a dev_handle. If not, it tests whether the current\ngrub_disk_dev is a memdisk and attempt to grub_shim_load_image.\n\nTODO: add secure boot verification. Whould this need a shim with netboot\nsupport?\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/d80a995d2f96c242973e3c1219d7ad7f14ea1753"},{"sha":"035b1410e4640636724141c5ab983055d74228ca","author":{"email":"b0ea9152ea2026377af95cd4fdb162e220f5b6e2@linux.intel.com","name":"Ricardo Neri"},"message":"grub: core: loader: pass current disk device to loaded image\n\nPass the disk device in use by GRUB to the loaded image. This useful\nfor the particular case of ramdisks so that they can be accessed\nby the loaded image.\n\nA backup copy of the disk device is saved so that it can be restored\nwhen the loaded image return to GRUB. This is useful the loaded image\nmight have modified the device (e.g., add elements to the disk list\nthat will not longer exist when returning to GRUB).\n\nSigned-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/01org/luv-yocto/commits/035b1410e4640636724141c5ab983055d74228ca"}]}