Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
Cc: Dan Horák <dan@danny.cz>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
`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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
It was annoying me.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|