The validate_power_state() handler checks the power_state for a valid afflvl
and state id. Although the afflvl check is common, the state ids are implementation
defined.
This patch moves the handler to the tegra/soc folder to allow each SoC to validate
the power_state for supported parameters.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch moves the inclusion of CPU code (A53, A57) to T210's
makefile. This way we can reduce code size for Tegra platforms by
including only the required CPU files.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
A new config, ENABLE_NS_L2_CPUECTRL_RW_ACCESS, allows Tegra platforms to
enable read/write access to the L2 and CPUECTRL registers. T210 is the
only platform that needs to enable this config for now.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch locks access to the PMC registers which hold the CPU reset
vector addresses. The PMC registers are used by the warmboot code and
must be locked during boot/resume to avoid booting into custom firmware
installed by unknown parties e.g. hackers.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
The PMC Scratch22 register contains the CPU reset vector to
be used by the warmboot code to power up the CPU while resuming
from system suspend. This patch locks this PMC register to avoid
any further writes.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch checks if the target CPU is already online before
proceeding with it's power ON sequence.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch de-asserts the CPU reset signals for each CPU as
part of it's power on sequence. This is needed to get rid of
the wait in BPMP firmware during SC7 exit.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch fixes the delay loop used to wake up the BPMP during SC7 exit.
The earlier loop would fail just when the timer was about to wrap-around
(e.g. when TEGRA_TMRUS_BASE is 0xfffffffe, the target value becomes 0,
which would cause the loop to exit before it's expiry).
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch introduces the backend required for implementing the delay
timer API. Tegra has an on-chip free flowing us timer which can be
used as the delay timer.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch sets the 'USE_COHERENT_MEM' flag to '0', so that the
coherent memory region will not be included in the memory map.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch implements the get_sys_suspend_power_state() handler required by
the PSCI SYSTEM_SUSPEND API. The intent of this handler is to return the
appropriate State-ID field which can be utilized in `affinst_suspend()` to
suspend to system affinity level.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.
Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.
A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.
The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.
The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.
On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.
REMOVED BUILD OPTIONS:
* 'AUTH_MOD'
Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image identifiers.
A new header file with TBBR image identifiers has been added.
Platforms that use the TBBR (i.e. ARM platforms) may reuse these
definitions as part of their platform porting.
PLATFORM PORT - IMPORTANT:
Default image IDs have been removed from the platform common
definitions file (common_def.h). As a consequence, platforms that
used those common definitons must now either include the IDs
provided by the TBBR header file or define their own IDs.
*The NVCounter authentication method has not been implemented yet.
Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
In case the platform returns a hash of the key:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
keyDigest OCTET STRING
}
An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:
- 'regs' : return the ROTPK hash stored in the Trusted
root-key storage registers.
- 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
BL2 binaries. This hash has been obtained from the development
RSA public key located in 'plat/arm/board/common/rotpk'.
On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.
A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.
Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.
This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.
As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.
A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.
Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.
The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.
IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.
Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
In order to handle secure/non-secure interrupts, overload the plat_ic_*
functions and copy GIC helper functions from arm_gic.c. Use arm_gic.c
as the reference to add Tegra's GIC helper functions.
Now that Tegra has its own GIC implementation, we have no use for
plat_gic.c and arm_gic.c files.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Add SP804 delay timer support to the FVP BSP.
This commit simply provides the 3 constants needed by the SP804
delay timer driver and calls sp804_timer_init() in
bl2_platform_setup(). The BSP does not currently use the delay
timer functions.
Note that the FVP SP804 is a normal world accessible peripheral
and should not be used by the secure world after transition
to the normal world.
Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
Co-authored-by: Dan Handley <dan.handley@arm.com>
This patch adds support to reserve a memory carveout region in the
DRAM on Tegra SoCs. The memory controller provides specific registers
to specify the aperture's base and size. This aperture can also be
changed dynamically in order to re-size the memory available for
DRM video playback. In case of the new aperture not overlapping
the previous one, the previous aperture has to be cleared before
setting up the new one. This means we do not "leak" any video data
to the NS world.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch adds support to run a Trusted OS during boot time. The
previous stage bootloader passes the entry point information in
the 'bl32_ep_info' structure, which is passed over to the SPD.
The build system expects the dispatcher to be passed as an input
parameter using the 'SPD=<dispatcher>' option. The Tegra docs have
also been updated with this information.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
For CSS based platforms, the constants MHU_SECURE_BASE and
MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
As such, they were misnamed because the mailboxes are completely
unrelated to the MHU hardware.
This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
The address of the Trusted Mailboxes is now relative to the base of
the Trusted SRAM.
This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
which is the address of the first memory region used for communication
between AP and SCP. This is used by the BOM and SCPI protocols.
Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.
On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.
Also update the documentation to reflect this change.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.
Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defect
did not have any observed regression.
Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a
On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.
However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.
This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.
ARM Trusted Firmware Design document updated accordingly.
Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
T210 is the latest chip in the Tegra family of SoCs from NVIDIA. It is an
ARM v8 dual-cluster (A57/A53) SoC, with any one of the clusters being active
at a given point in time.
This patch adds support to boot the Trusted Firmware on T210 SoCs. The patch
also adds support to boot secondary CPUs, enter/exit core power states for
all CPUs in the slow/fast clusters. The support to switch between clusters
is still not available in this patch and would be available later.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch fixes the incorrect bit width used to extract the primary
cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in
platform_is_primary_cpu().
Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa
Fix the return type of the FVP `plat_arm_topology_setup` function
to be `void` instead of `int` to match the declaration in
`plat_arm.h`.
This does not result in any change in behavior.
Change-Id: I62edfa7652b83bd26cffb7d167153959b38e37e7
There has been a breaking change in the communication protocols used
between the AP cores and the SCP on CSS based platforms like Juno.
This means both the AP Trusted Firmware and SCP firmware must be
updated at the same time.
In case the user forgets to update the SCP ROM firmware, this patch
detects when it still uses the previous version of the communication
protocol. It will then output a comprehensive error message that helps
trouble-shoot the issue.
Change-Id: I7baf8f05ec0b7d8df25e0ee53df61fe7be0207c2
The communication protocol used between the AP cores and the SCP
in CSS-based platforms like Juno has undergone a number of changes.
This patch makes the required modifications to the SCP Boot Protocol,
SCPI Protocol and MHU driver code in shared CSS platform code so that
the AP cores are still able to communicate with the SCP.
This patch focuses on the mandatory changes to make it work. The
design of this code needs to be improved but this will come in
a subsequent patch.
The main changes are:
- MHU communication protocol
- The command ID and payload size are no longer written into the
MHU registers directly. Instead, they are stored in the payload
area. The MHU registers are now used only as a doorbell to kick
off messages. Same goes for any command result, the AP has to
pick it up from the payload area.
- SCP Boot Protocol
- The BL3-0 image is now expected to embed a checksum. This
checksum must be passed to the SCP, which uses it to check the
integrity of the image it received.
- The BL3-0 image used to be transferred a block (4KB)
at a time. The SCP now supports receiving up to 128KB at a
time, which is more than the size of the BL3-0 image.
Therefore, the image is now sent in one go.
- The command IDs have changed.
- SCPI Protocol
- The size of the SCPI payload has been reduced down from 512
bytes to 256 bytes. This changes the base address of the
AP-to-SCP payload area.
- For commands that have a response, the response is the same SCPI
header that was sent, except for the size and the status, which
both must be updated appropriately. Success/Failure of a command
is determined by looking at the updated status code.
- Some command IDs have changed.
NOTE: THIS PATCH BREAKS COMPATIBILITY WITH FORMER VERSIONS OF THE SCP
FIRMWARE AND THUS REQUIRES AN UPDATE OF THIS BINARY. THE LATEST SCP
BINARY CAN BE OBTAINED FROM THE ARM CONNECTED COMMUNITY WEBSITE.
Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7
Move the Juno port from plat/juno to plat/arm/board/juno. Also rename
some of the files so they are consistently prefixed with juno_.
Update the platform makefiles accordingly.
Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
Major update to the Juno platform port to use the common platform code
in (include/)plat/arm/* and (include/)plat/common/*. This mainly
consists of removing duplicated code but also introduces some small
behavioural changes where there was unnecessary variation between the
FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
platform code` for details.
Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe
initialization) from BL1 to `plat_arm_security_setup()` in BL2,
where the other security setup is done.
Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
some of the files so they are consistently prefixed with fvp_.
Update the platform makefiles accordingly.
Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
Major update to the FVP platform port to use the common platform code
in (include/)plat/arm/* and (include/)plat/common/*. This mainly
consists of removing duplicated code but also introduces some small
behavioural changes where there was unnecessary variation between the
FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
platform code` for details.
Also add support for Foundation FVP version 9.1 during FVP config
setup to prevent a warning being emitted in the console.
Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
This major change pulls out the common functionality from the
FVP and Juno platform ports into the following categories:
* (include/)plat/common. Common platform porting functionality that
typically may be used by all platforms.
* (include/)plat/arm/common. Common platform porting functionality
that may be used by all ARM standard platforms. This includes all
ARM development platforms like FVP and Juno but may also include
non-ARM-owned platforms.
* (include/)plat/arm/board/common. Common platform porting
functionality for ARM development platforms at the board
(off SoC) level.
* (include/)plat/arm/css/common. Common platform porting
functionality at the ARM Compute SubSystem (CSS) level. Juno
is an example of a CSS-based platform.
* (include/)plat/arm/soc/common. Common platform porting
functionality at the ARM SoC level, which is not already defined
at the ARM CSS level.
No guarantees are made about the backward compatibility of
functionality provided in (include/)plat/arm.
Also remove any unnecessary variation between the ARM development
platform ports, including:
* Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
Juno implementation, which copies the information from BL2 memory
instead of expecting it to persist in shared memory.
* Unify the TZC configuration. There is no need to add a region
for SCP in Juno; it's enough to simply not allow any access to
this reserved region. Also set region 0 to provide no access by
default instead of assuming this is the case.
* Unify the number of memory map regions required for ARM
development platforms, although the actual ranges mapped for each
platform may be different. For the FVP port, this reduces the
mapped peripheral address space.
These latter changes will only be observed when the platform ports
are migrated to use the new common platform code in subsequent
patches.
Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
Some assembly files containing macros are included like header files
into other assembly files. This will cause assembler errors if they
are included multiple times.
Add header guards to assembly macro files to avoid assembler errors.
Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69
The required platform constant PLATFORM_CACHE_LINE_SIZE is
unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
same information. CACHE_WRITEBACK_GRANULE is preferred since this
is an architecturally defined term and allows comparison with the
corresponding hardware register value.
Replace all usage of PLATFORM_CACHE_LINE_SIZE with
CACHE_WRITEBACK_GRANULE.
Also, add a runtime assert in BL1 to check that the provided
CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
Change-Id: If87286be78068424217b9f3689be358356500dcd
In order for the symbol table in the ELF file to contain the size of
functions written in assembly, it is necessary to report it to the
assembler using the .size directive.
To fulfil the above requirements, this patch introduces an 'endfunc'
macro which contains the .endfunc and .size directives. It also adds
a .func directive to the 'func' assembler macro.
The .func/.endfunc have been used so the assembler can fail if
endfunc is omitted.
FixesARM-Software/tf-issues#295
Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
Signed-off-by: Kévin Petit <kevin.petit@arm.com>
For Juno r0, the platform reset handler needs to:
- Implement the workaround for defect #831273
- Increase the L2 Data and Tag RAM latencies for Cortex-A57.
Defect #831273 does not affect Juno r1. Also, the default value
for the L2 Tag RAM latency for Cortex-A57 is suitable on Juno r1.
The L2 Data RAM latency for Cortex-A57 still needs to be
increased, though.
This patch modifies the Juno platform reset handler to detect
the board revision and skip the unnecessary steps on Juno r1.
The behaviour on Juno r0 is unchanged.
Change-Id: I27542917223e680ef923ee860900806ffcd0357b
This patch updates the FVP and Juno platform ports to use the common
driver for ARM Cache Coherent Interconnects.
Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542
This patch defines the ARRAY_SIZE macro for calculating number of elements
in an array and uses it where appropriate.
Change-Id: I72746a9229f0b259323972b498b9a3999731bc9b
Cortex-A57 erratum #806969 applies to revision r0p0 of the CPU
but does not manifest itself on Juno r0. It is not applicable
to Juno r1 in any case.
This patch modifies the Juno platform Makefile to no longer
compile this erratum workaround in.
Change-Id: I32b16835b2ac897e639e869ab2b78b62a51a0139
This patch modifies the declarations of the functions printf() et al.
and adds the right GCC attribute to request the compiler to check
the type of the arguments passed to these functions against the given
format string. This will ensure that the compiler outputs warning
messages like the following whenever it detects an inconsistency:
file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
It also fixes the type mismatch inconsistencies that it revealed
across the code base.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE
PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.
Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6
All coding style violations have been fixed in a previous patch and
since then, each individual patch has been checked in this regard.
However, the latest version of the checkpatch.pl script from the Linux
kernel is more advanced and it is able to flag new errors in the
Trusted Firmware codebase. This patch fixes them.
Change-Id: I1f332f2440984be85d36b231bb83260368987077
By default the SMMU for the DMA-330 is configured to mark some stream IDs
as always belonging to the Secure world. As a result, if EL1 software turns
the SMMU on, certain Non-Secure accesses get rewritten as Secure, making
them bypass translation and access Secure physical addresses directly.
Since the current Juno board firmware configures the DMA-330 hardware as
Non-Secure, rewrite the SMMU's default SSD table as well to prevent any
unexpected behaviour in EL1.
Change-Id: Iaa81d883eecf28d80eb182b9ce475684bf9c718c
This patch removes the plat_get_max_afflvl() platform API
and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL.
This is done because the maximum affinity level for a platform
is a static value and it is more efficient for it to be defined
as a platform macro.
NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT
FixesARM-Software/tf-issues#265
Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf
This patch defines MAX_MMAP_REGIONS separately for each BL stage
as per its requirements. This minimizes the size of the mmap[]
array.
FixesARM-Software/tf-issues#201
Change-Id: I19b15e1a91a8365b2ecf24e2cd71937cb73916b2
This patch adds support to authenticate the Trusted Key certificate
and the BL3-x certificates and images at BL2.
Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd
This patch moves fvp_io_setup() to bl2_early_platform_setup() in order
to allow BL2 to use the IO framework before bl2_platform_setup().
Change-Id: I75e1a772ab5f9b4727f6727822a2527c30f3c63d
This patch adds support to authenticate the BL2 content certificate
and image using the authentication module in BL1.
The FIP driver has been extended to include the BL2 certificate
UUID.
FVP and Juno ports include the BL2 certificate FIP file
definition.
Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
This patch implements an authentication module based on the
PolarSSL library (v1.3.9) to verify the Chain of Trust when
Trusted Boot is enabled.
PolarSSL sources must be fetched separately. The POLARSSL_DIR
build option may be used to indicate the path to the PolarSSL
main directory (this directory must contain the 'include' and
'library' subdirectories).
To be able to build PolarSSL sources as a part of the Trusted
Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk
will tell the build system to remove the -pedantic option from
the CFLAGS.
Inclusion of PolarSSL increases the memory requirements of the BL1
and BL2 images. The following are the changes made to the FVP and
Juno platforms to cater for this when TRUSTED_BOARD_BOOT is
defined:
Changes on FVP:
- BL1 and BL2 stacks have been increased to 4 KB
- BL1(rw) section has been increased to 32 KB.
- BL2 memory region has been increased to 112 KB
Changes on Juno:
- BL1 and BL2 stacks have been increased to 4 KB
- BL1(rw) section has been increased to 32 KB.
- Trusted ROM region in Flash has been increased to 128 KB.
- BL2 memory region has been increased to 116 KB
Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
Varun Wadekar
Juan Castillo
Ryan Harkin
Sandrine Bailleux
Soby Mathew
Dan Handley
Kévin Petit
Vikram Kanigiri
Robin Murphy