| commit | 364c194df5415d5907d568b931eb72510c2606b7 | [log] [tgz] |
|---|---|---|
| author | Rupert Swarbrick <rswarbrick@lowrisc.org> | Thu May 28 17:17:40 2020 +0100 |
| committer | Philipp Wagner <mail@philipp-wagner.com> | Thu May 28 17:41:37 2020 +0100 |
| tree | 55c72387e3a17f2099da5c2303f078fe19dfc412 | |
| parent | befd89b0154072d7f511fbb20732aabd81218226 [diff] |
[util] Correctly cope with patch_dir and no mapping in vendor.py This was broken with my recent patch to add "mapping" support. The fix passes a boolean flag to Mapping1.make_default saying "please add a relative patch directory of '.' to the dummy mapping entry you make". This patch also fixes how we run "git apply" to apply the patches. It turns out that if you run cd subdir/in/repo git apply my.patch then the paths in my_path are interpreted relative to the root of the repository (and anything that applies to a file outside of subdir/in/repo is skipped). Before the recent vendoring changes, we applied the patches before copying into the target repository. So it was something like git clone git://something /tmp/something (cd /tmp/something; git apply -p1 /path/to/my.patch) cp /tmp/something/* vendor/something I'm not sure this would work with only_subdir, but it definitely did work correctly if we were copying from the top of the vendored repo. The recent vendoring changes alter things to: git clone git://something /tmp/something cp /tmp/something/* vendor/something (cd vendor/something; git apply -p1 /path/to/my.patch) This doesn't do what you want, because the paths in the patch look like a/myfile.c rather than a/vendor/something/myfile.c (and the hunks all get skipped). We can fix things up again by using the --directory argument to git apply, which works a bit like you might expect changing directory to vendor/something would work and changes how the patch paths are interpreted. Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
OpenTitan is an open source silicon Root of Trust (RoT) project. OpenTitan will make the silicon RoT design and implementation more transparent, trustworthy, and secure for enterprises, platform providers, and chip manufacturers. OpenTitan is administered by lowRISC CIC as a collaborative project to produce high quality, open IP for instantiation as a full-featured product. See the OpenTitan site and OpenTitan docs for more information about the project.
This repository contains hardware, software and utilities written as part of the OpenTitan project. It is structured as monolithic repository, or “monorepo”, where all components live in one repository. It exists to enable collaboration across partners participating in the OpenTitan project.
The project contains comprehensive documentation of all IPs and tools. You can access it online at docs.opentitan.org.
Have a look at CONTRIBUTING for guidelines on how to contribute code to this repository.
Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).