Re: WARNING: Unimplemented Standard Service Call:

On Jun 21, 2025, at 15:08, Bjoern A. Zeeb <[email protected]> wrote:

> On Sat, 21 Jun 2025, Rebecca Cran wrote:
> 
>> What system? From the message it sounds like the TF-A firmware isn't implementing a standard service call that should exist.
> 
> To my very best knowledge I have not seen these WARNINGs in the last
> two-ish years.  Hence me asking what changed on FreeBSD that they do show up
> now and if we need to do some things connditionally on flags or
> otherwise?
> 
> Or, given the thought came, if we do now rely on a specific minimum and
> that needs to be documented/enforced.
> 
> 
>> With some systems you can build the TF-A firmware yourself, but others it's provided as a binary you include as part of the UEFI build when producing a SPI-NOR image.
> 
> Yeah, this is a u-boot system and I do have access to the TF-A sources
> from a public repo but rebasing them will be challenging I bet.
> I believe they are based on v1.5 and then updated by manufacturer for years
> and provided to vendor who put further fixes on top for various memory
> issues for the SoC.
> 
> This system of (Linux) embedded people is so unsustainable.  I am tired
> of having to do firmware updates and builds for almost every SoC that
> goes through my hands these days *sigh*.
> 
> I assume I'll have to bite the bullet but I really would love to
> understand which chnages on FreeBSD started triggering the WARNINGs.

They are warnings only in pre-2021-May-04 based arm-trusted-firmware.
After that the message reclassfied as VERBOSE instead of WARN. 

None of the following occur in the FreeBSD source for the PkgBase'd
/usr/src/sys/ for main that I have here:

0x840000F0
0x840000f0
ARM_EM_VERSION

0x84000050
ARM_TRNG_VERSION

So I've got only more generic information.


For reference:

/* Register Standard Service Calls as runtime service */
DECLARE_RT_SVC(
		std_svc,

		OEN_STD_START,
		OEN_STD_END,
		SMC_TYPE_FAST,
		std_svc_setup,
		std_svc_smc_handler
);

It is std_svc_smc_handler that has the message.


Maybe when ARM_EM_VERSION or ARM_TRNG_VERSION was added
to arm-trusted-firmware might help identify the calling
context? ARM_EM_VERSION is more recent, as it turns out.


ARM_EM_VERSION was added in:

arm-trusted-firmware/include/services/errata_abi_svc.h

Commit History
Commits on May 5, 2023

feat(errata_abi): errata management firmware interface
This patch adds the errata management firmware interface for lower ELs
to discover details about CPU erratum. Based on the CPU erratum
identifier the interface enables the OS to find the mitigation of an
erratum in EL3.

The ABI can only be present in a system that is compliant with SMCCCv1.1
or higher. This implements v1.0 of the errata ABI spec.

For details on all possible return values, refer the design
documentation below:

ABI design documentation:
https://developer.arm.com/documentation/den0100/1-0?lang=en

Signed-off-by: Sona Mathew <[email protected]>
Change-Id: I70f0e2569cf92e6e02ad82e3e77874546232b89a
SonaMathew-arm
SonaMathew-arm


ARM_TRNG_VERSION was added in:

arm-trusted-firmware/‎include/services/trng_svc.h

Commit 7dfb991
theotherjimmy
authored and
manish-pandey-arm
committed on Feb 5, 2021

Add TRNG Firmware Interface serviceThis adds the TRNG Firmware Interface
Service to the standard service dispatcher. This includes a method for 
ispatching entropy requests to platforms and includes an entropy pool
implementation to avoid dropping any entropy requested from the platform.

Change-Id: I71cadb3cb377a507652eca9e0d68714c973026e9
Signed-off-by: Jimmy Brisson <[email protected]>
Signed-off-by: Andre Przywara <[email protected]>


So it looks like whatever is using ARM_EM_VERSION would
be more recent than May 5, 2023 or so.


===
Mark Millard
marklmi at yahoo.com