aboutsummaryrefslogtreecommitdiff
path: root/external/gard
AgeCommit message (Collapse)AuthorFilesLines
2021-08-06external/gard: Enable Power10Klaus Heinrich Kiwi4-3/+103
Add Power10 support for opal-gard utility. Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> [Folded test case fix and updated commit message - Vasant] Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-06-03opal-gard: sync up the chip unit data list with upstream hostboot.Mahesh Salgaonkar1-1/+9
opal-gard on POWER9P system fails to identify few chip targets while displaying gard records. This patch fixes that. Before: # opal-gard list ID | Error | Type | Path ------------------------------------------------------------------------------- 00000001 | 90004af4 | Predictive | /Sys0/Node0/Proc0/MC0/MI0/UNKNOWN0/UNKNOWN0 =============================================================================== After this patch: # ./opal-gard list ID | Error | Type | Path --------------------------------------------------------------------------- 00000001 | 90004af4 | Predictive | /Sys0/Node0/Proc0/MC0/MI0/MCC0/OMI0 =========================================================================== Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Dan Horák <dan@danny.cz> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-13Re-license contributions from Dan HorákOliver O'Halloran1-1/+1
Cc: Dan Horák <dan@danny.cz> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-12Re-license IBM written files as Apache 2.0 OR GPLv2+Stewart Smith5-5/+5
SPDX makes it a simpler diff. I have audited the commit history of each file to ensure that they are exclusively authored by IBM and thus we have the right to relicense. The motivation behind this is twofold: 1) We want to enable experiments with coreboot, which is GPLv2 licensed 2) An upcoming firmware component wants to incorporate code from skiboot and code from the Linux kernel, which is GPLv2 licensed. I have gone through the IBM internal way of gaining approval for this. The following files are not exclusively authored by IBM, so are *not* included in this update (I will be seeking approval from contributors): core/direct-controls.c core/flash.c core/pcie-slot.c external/common/arch_flash_unknown.c external/common/rules.mk external/gard/Makefile external/gard/rules.mk external/opal-prd/Makefile external/pflash/Makefile external/xscom-utils/Makefile hdata/vpd.c hw/dts.c hw/ipmi/ipmi-watchdog.c hw/phb4.c include/cpu.h include/phb4.h include/platform.h libflash/libffs.c libstb/mbedtls/sha512.c libstb/mbedtls/sha512.h platforms/astbmc/barreleye.c platforms/astbmc/garrison.c platforms/astbmc/mihawk.c platforms/astbmc/nicole.c platforms/astbmc/p8dnu.c platforms/astbmc/p8dtu.c platforms/astbmc/p9dsu.c platforms/astbmc/vesnin.c platforms/rhesus/ec/config.h platforms/rhesus/ec/gpio.h platforms/rhesus/gpio.c platforms/rhesus/rhesus.c platforms/astbmc/talos.c platforms/astbmc/romulus.c Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: fixed up the drift] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-12opal-gard: Add support for new PVR POWER9P.Mahesh Salgaonkar1-0/+1
Enable a new PVR for gard tool to work on another p9 variant. Makes op-test as well happy. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> [oliver: s/Axone/axone/] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-10-22gard: Add support to run gard tests on FSP platformVasant Hegde2-6/+11
gard tool is not supported on FSP based system. But we can still run gard tests on FSP based system. Acked-by: Stewart Smith <stewart@flamingspork.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-10-14blocklevel: smart_write: Fix unaligned writes to ECC partitionsAndrew Jeffery3-0/+39
Currently trying to clear a gard record results in errors: $ ./opal-gard -pef part create /sys0/node0/proc1 $ ./opal-gard -pef part list ID | Error | Type | Path --------------------------------------------------------- 00000001 | 00000000 | Manual | /Sys0/Node0/Proc1 ========================================================= $ ./opal-gard -pef part clear 00000001 Clearing gard record 0x00000001...done ECC: uncorrectable error: ffffff00ffffffff ff libflash ecc invalid $ A little wrapper around hexdump(1) helps show where the error lies by grouping output in blocks of nine such that the last byte is the ECC byte: $ declare -f ecchd ecchd () { hexdump -e '"%08_ax""\t"' -e '9/1 "%02x ""\t""|"' -e '9/1 "%_p""|\n"' "$@" } A clean GARD partition displays as: $ ecchd part 0002c000 ff ff ff ff ff ff ff ff 00 |.........| * 00030ffb ff ff ff ff ff |.....| $ Dumping the corrupt partition shows: $ ecchd part 0002c000 ff ff ff ff ff ff ff ff 00 |.........| * 0002c024 ff ff ff ff ff ff ff ff ff |.........| 0002c02d ff ff ff 00 ff ff ff ff ff |.........| * 0002c051 ff ff ff 00 ff ff ff ff 00 |.........| 0002c05a ff ff ff ff ff ff ff ff 00 |.........| * 00030ffb ff ff ff ff ff |.....| $ blocklevel_smart_write() turned out to not be quite as smart as it thought it was in that any unaligned write to ECC protected partitions aligned the calculated ECC values to the start of the write buffer and not relative to the start of the partition. Fixes: 29d1e6f78109 ("libflash/blocklevel: add a smart write function which wraps up eraseing and writing") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-10-14gard: Fix data corruption when clearing single recordsAndrew Jeffery4-1/+31
Attempting to clear a specific gard record leads to corruption of the target record rather than the expected removal: $ ./opal-gard -f romulus.pnor list No GARD entries to display $ ./opal-gard -f romulus.pnor create /sys0/node0/proc1 $ ./opal-gard -f romulus.pnor list ID | Error | Type | Path --------------------------------------------------------- 00000001 | 00000000 | Manual | /Sys0/Node0/Proc1 ========================================================= $ ./opal-gard -f romulus.pnor clear 00000001 Clearing gard record 0x00000001...done $ ./opal-gard -f romulus.pnor list ID | Error | Type | Path --------------------------------------------------------- 00000001 | 00000000 | Unknown | /Sys0/Node0/Proc1 ========================================================= The GUARD partition needs to be compacted when clearing records as the end of the list is a sentinel represented by the erased-flash state. The compaction strategy is to read the trailing records and write them to the offset of the record to be removed, followed by writing the sentinel record at the offset of what was previously the last valid record. The corruption occurs due to incorrect calculation of the offset at which the trailing records will be written. Cc: Skiboot Stable <skiboot-stable@lists.ozlabs.org> Fixes: 5616c42d900a ("libflash/blocklevel: Make read/write be ECC agnostic for callers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26SPDX-ify all skiboot codeStewart Smith7-30/+19
Use Software Package Data Exchange (SPDX) to indicate license for each file that is unique to skiboot. At the same time, ensure the (C) who and years are correct. See https://spdx.org/ Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: Added a few missing files] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26gard: fix installation ruleDan Horák1-2/+2
Use $(EXE) for the binary name instead of hard-coding. This completes the "gard: Use consistent name" change from commit 41109e5073bd ("gard: Use consistent name") Fixes: 41109e5073bd ("gard: Use consistent name") Signed-off-by: Dan Horák <dan@danny.cz> [oliver: prefix in title, fixes tag] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-05-20opal-gard: Account for ECC size when clearing partitionOliver O'Halloran1-1/+2
When 'opal-gard clear all' is run, it works by erasing the GUARD then using blockevel_smart_write() to write nothing to the partition. This second write call is needed because we rely on libflash to set the ECC bits appropriately when the partition contained ECCed data. The API for this is a little odd with the caller specifying how much actual data to write, and libflash writing size + size/8 bytes since there is one additional ECC byte for every eight bytes of data. We currently do not account for the extra space consumed by the ECC data in reset_partition() which is used to handle the 'clear all' command. Which results in the paritition following the GUARD partition being partially overwritten when the command is used. This patch fixes the problem by reducing the length we would normally write by the number of ECC bytes required. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Tested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-05-20gard: Use consistent nameVasant Hegde13-16/+16
During compilation we generates binary file as "gard" and during installation we install it as "opal-gard". This seems to be creating some confusion. Some people are thinking these are two different tools. Hence lets use common name for gard tool ("opal-gard"). Cc: Oliver O'Halloran <oohall@gmail.com> Cc: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-02-21Makefile: Paper over gard and pflash coverage issuesAndrew Jeffery1-0/+4
`make coverage-report` gave the following error: (cd external/pflash; lcov -q -c -d . -o pflash.info --rc lcov_branch_coverage=1; sed -i -e 's%external/pflash/libflash%libflash%; s%external/pflash/ccan%ccan%' pflash.info) (cd external/gard; lcov -q -c -d . -o gard.info --rc lcov_branch_coverage=1; sed -i -e 's%external/gard/libflash%libflash%; s%external/gard/ccan%ccan%' gard.info) geninfo: WARNING: no .gcda files found in . - skipping! geninfo: WARNING: no .gcda files found in . - skipping! lcov -q -c -d . -d ccan/check_type/test/ -d ccan/str/test/ -d ccan/str/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/build_assert/test/ -d ccan/short_types/test/ -d ccan/short_types/test/ -d ccan/array_size/test/ -d ccan/container_of/test/ -d ccan/endian/test/ -d libc/test/ -d libc/test/ -d libc/test/ -d libc/test/ -o skiboot.info --rc lcov_branch_coverage=1 lcov -q -r skiboot.info 'external/pflash/*' -o skiboot.info lcov -q -r skiboot.info 'external/gard/*' -o skiboot.info lcov -q -a skiboot.info -a external/pflash/pflash.info -o skiboot.info lcov: ERROR: no valid records found in tracefile external/pflash/pflash.info make: *** [/home/andrew/src/open-power/skiboot/Makefile.main:315: skiboot.info] Error 255 And similar again for the gard tool. We should really untangle the build strategy for tools in external/, but in the mean time paper over the problem of generating the lcov output at the top level by ensuring we have a means to generate the necessary gcda files for lcov to consume. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-02-21gard: Fix warnings from gcc 8.2.0Andrew Jeffery1-2/+3
gard.c:285:5: error: no previous prototype for ‘parse_path’ [-Werror=missing-prototypes] int parse_path(const char *str, struct entity_path *parsed) ^~~~~~~~~~ gard.c: In function ‘do_list’: gard.c:459:46: error: unused parameter ‘argc’ [-Werror=unused-parameter] static int do_list(struct gard_ctx *ctx, int argc, char **argv) ~~~~^~~~ gard.c:459:59: error: unused parameter ‘argv’ [-Werror=unused-parameter] static int do_list(struct gard_ctx *ctx, int argc, char **argv) ~~~~~~~^~~~ Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-05-29Add -Wno-stringop-truncation for GCC8Stewart Smith1-1/+1
This warning appears to not be particularly useful if you ever actually *want* to truncate a string. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-04-09libflash/blocklevel: Make read/write be ECC agnostic for callersCyril Bur1-32/+17
The blocklevel abstraction allows for regions of the backing store to be marked as ECC protected so that blocklevel can decode/encode the ECC bytes into the buffer automatically without the caller having to be ECC aware. Unfortunately this abstraction is far from perfect, this is only useful if reads and writes are performed at the start of the ECC region or in some circumstances at an ECC aligned position - which requires the caller be aware of the ECC regions. The problem that has arisen is that the blocklevel abstraction is initialised somewhere but when it is later called the caller is unaware if ECC exists in the region it wants to arbitrarily read and write to. This should not have been a problem since blocklevel knows. Currently misaligned reads will fail ECC checks and misaligned writes will overwrite ECC bytes and the backing store will become corrupted. This patch add the smarts to blocklevel_read() and blocklevel_write() to cope with the problem. Note that ECC can always be bypassed by calling blocklevel_raw_() functions. All this work means that the gard tool can can safely call blocklevel_read() and blocklevel_write() and as long as the blocklevel knows of the presence of ECC then it will deal with all cases. This also commit removes code in the gard tool which compensated for inadequacies no longer present in blocklevel. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> [stewart: core/flash: Adapt to new libflash ECC API Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-03-14Make gard display show that a record is clearedDan Crowell1-3/+4
When clearing gard records, Hostboot only modifies the record_id portion to be 0xFFFFFFFF. The remainder of the entry remains. Without this change it can be confusing to users to know that the record they are looking at is no longer valid.
2017-12-01gard: Add testsOliver O'Halloran22-2/+148
I hear Stewart likes these for some reason. Dunno why. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Fix up do_create return valuesOliver O'Halloran1-4/+4
The return value of a subcommand is interpreted as a libflash error code when it's positive or some subcommand specific error when negative. Currently the create subcommand always returns zero when exiting (even for errors) so fix that. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Delete stale commentOliver O'Halloran1-6/+0
This comment referred to some previously deleted code. It can go. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Add usage message for -pOliver O'Halloran1-0/+1
The -p argument only really makes sense when -f is specified. Print an actual error message rather than just the usage blob. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Fix max instance countOliver O'Halloran1-2/+2
There's an entire byte for the instance count rather than a nibble. Only barf if the instance number is beyond 255 rather than 16. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Fix up path parsingOliver O'Halloran1-1/+1
Currently we assume that the Unit ID can be used as an array index into the chip_units[] structure. There are holes in the ID space though, so this doesn't actually work. Fix it up by walking the array looking for the ID. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Set chip generation based on PVROliver O'Halloran1-10/+42
Currently we assume that this tool is being used on a P8 system by default and allow the user to override this behaviour using the -8 and -9 command line arguments. When running on the host we can use the PVR to guess what chip generation so do that. This also changes the default behaviour to assume that the host is a P9 when running on an ARM system. This tool didn't even work when compiled for ARM until recently and the OpenBMC vPNOR hack that we have currently is broken for P9 systems that don't use vPNOR (Zaius and Romulus). Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-12-01gard: Allow records with an ID of 0xffffffffOliver O'Halloran1-3/+4
We currently assume that a record with an ID of 0xffffffff is invalid. Apparently this is incorrect and we should display these records, so expand the check to compare the entire record with 0xff rather than just the ID. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Add OpenBMC vPNOR supportOliver O'Halloran1-0/+31
A big-ol-hack to add some checking for OpenBMC's vPNOR GUARD files under /media/pnor-prsv. This isn't ideal since it doesn't handle the create case well, but it's better than nothing. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Always use MTD to access flashOliver O'Halloran1-0/+8
Direct mode is generally either unsafe or unsupported. We should always access the PNOR via an MTD device so make that the default. If someone really needs direct mode, then they can use pflash. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: create: Allow creating arbitrary GARD recordsOliver O'Halloran2-4/+76
Add a new sub-command that allows us to create GARD records for arbitrary chip units. There isn't a whole lot of constraints on this and that limits how useful it can be, but it does allow a user to GARD out individual DIMMs, chips or cores from the BMC (or host) if needed. There are a few caveats though: 1) Not everything can, or should, have a GARD record applied it to. 2) There is no validation that the unit actually exists. Doing that sort of validation requires something that understands the FAPI targeting information (I think) and adding support for it here would require some knowledge from the system XML file. 3) There's no way to get a list of paths in the system. 4) Although we can create a GARD record at runtime it won't be applied until the next IPL. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Add path parsing supportOliver O'Halloran1-0/+87
In order to support manual GARD records we need to be able to parse the hardware unit path strings. This patch implements that. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: list: Improve outputOliver O'Halloran2-25/+68
Display the full aath to the GARDed hardware unit in each record rather than relying on the output of `gard show` and convert do_list() to use the iterator while we're here. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: {list, show}: Fix the Type field in the outputOliver O'Halloran4-3/+49
The output of `gard list` has a field named "Type", however this doesn't actually indicate the type of the record. Rather, it shows the type of the path used to identify the hardware being GARDed. This is of pretty dubious value considering the Physical path seems to always be used when referring to GARDed hardware. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Use iterators for count_record()Oliver O'Halloran1-41/+12
Starting coverting code to use the iterators and fix some bad naming along the way. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Add iteratorsOliver O'Halloran1-0/+31
Add a `for_each_gard` iterator rather than using do_iterate. Callbacks are banned under the Genoa convention and we need to apply a zero-tolerance policy. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Replace is_valid_id with is_valid_record()Oliver O'Halloran1-4/+4
It was annoying me. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Add P9 supportOliver O'Halloran6-2/+46
Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: Update chip unit dataOliver O'Halloran5-121/+187
Source the list of units from the hostboot source rather than the previous hard coded list. The list of path element types changes between generations so we need to add a level of indirection to accommodate P9. This also changes the names used to match those printed by Hostboot at IPL time and paves the way to adding support for manual GARD record creation. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-11-20gard: show: Remove "Res Recovery" fieldOliver O'Halloran2-2/+0
This field has never been populated by hostboot on OpenPower systems so there's no real point in reporting it's contents. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-10-06external/gard: Clear entire guard partition instead of entry by entrySuraj Jitindar Singh1-11/+18
When using the current implementation of the gard tool to ecc clear the entire GUARD partition it is done one gard record at a time. While this may be ok when accessing the actual flash this is very slow when done from the host over the mbox protocol (on the order of 4 minutes) because the bmc side is required to do many read, erase, writes under the hood. Fix this by rewriting the gard tool reset_partition() function. Now we allocate all the erased guard entries and (if required) apply ecc to the entire buffer. Then we can do one big erase and write of the entire partition. This reduces the time to clear the guard partition to on the order of 4 seconds. Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-09-12external/gard: Print an error if run on an FSP systemCyril Bur1-1/+14
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-08-01external: Consolidate Makefile.check for external toolsCyril Bur1-26/+0
The reason for this is that check targets for one tool will start to depend on other tools. For example, future pflash tests will rely on ffspart to generate pnors. The current method is too racey and results in races cleaning/building ffspart for its tests and for pflash tests. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-08-01Makefile.check: Fix `make check`Cyril Bur1-5/+14
Recent reworks were tested on the travis-ci system. Unfortunately, there are configurations of running `make check` which the travis-ci doesn't do. On some systems extra problems crop up. Removing the stack size check is only done for the host compiler as the check is only critical for skiboot its self where stack space is contained. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-07-19gcov: properly handle gard and pflash code coverageStewart Smith1-1/+7
We end up with a bit of a nasty hack to count the libflash symlinks in gard and pflash as part of libflash code coverage, but it does work and is unlikely to break anytime soon. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-07-19gard: enable building with -DDEBUG for ccan listStewart Smith1-1/+8
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-07-19gard: enable building with skiboot HOSTCFLAGS warningsStewart Smith1-1/+21
Mostly unused parameter warnings due to callbacks Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-04-07external/gard: Use blocklevel_smart_erase()Cyril Bur1-1/+1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2017-02-23external/gard: Fix make dist targetCyril Bur4-12/+20
Several problems: Firstly, it could never have worked, it was using the wrong variable. Secondly, if it was using GARD_VERSION it produced a broken tarball that still looked into the skiboot source for files despite them having been copied into the tarball. Lastly (and not really a make dist issue) the current way of symlinking make_version.sh was racey. Get around the issue by refering to it in its actual location (if we know it will be there) or by looking at .version if building from tarball. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-11-02gard: Fix printf warningJoel Stanley1-1/+2
With a modern GCC targetting ARM 32-bit: gard.c: In function 'main': gard.c:652:19: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka long long unsigned int}' [-Werror=format=] fprintf(stderr, "MTD device bigger than %i: size:%lu\n", Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-09-22gard/pflash: Honor linker flags passed from the environmentFrederic Bonnard1-1/+1
Let use LDFLAGS from the environment for gard and pflash Debian/Ubuntu use this mechanism to do hardened builds. Signed-off-by: Frederic Bonnard <frediz@linux.vnet.ibm.com> [stewart@linux.vnet.ibm.com: also use LDFLAGS for pflash] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-09-22gard: Fix Makefile race conditionPatrick Williams1-1/+5
Commit fd599965 added some dependencies in 'external/pflash' for libflash files that are created via symlink. Replicate that same behavior in 'external/gard' to prevent race conditions where we attempt to compile files from libflash before they are symlink'd. Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-02flash: Make size 64 bit safeMichael Neuling1-1/+10
This makes the size of flash 64 bit safe so that we can have flash devices greater than 4GB. This is especially useful for mambo disks passed through to Linux. Fortunately the device tree interface and the linux device driver are 64bit safe so no changes are required there. Userspace gard and flash tools are also updated to ensure "make check" still passes. Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
generated by cgit v1.1 at 2024-09-08 11:45:13 +0000