That's exactly what I did. The SecPei variant has no globals and always probes (but can't read, only writes)

Will send an updated patch set later today.

A
________________________________
От: Sunil V L <sunilvl@ventanamicro.com>
Отправлено: четверг, марта 2, 2023 4:35 AM
Кому: devel@edk2.groups.io <devel@edk2.groups.io>; Warkentin, Andrei <andrei.warkentin@intel.com>
Копия: Kinney, Michael D <michael.d.kinney@intel.com>; kraxel@redhat.com <kraxel@redhat.com>; Daniel Schaefer <git@danielschaefer.me>
Тема: Re: [edk2-devel] [edk2 2/2] MdePkg: add BaseSerialPortLibRiscVSbi

Hi Andrei,

It is not just mLastGetChar but mHaveDbcn also will have the same issue
with XIP. So, I am wondering why not probe for the extension in every write
for the SecPei case? I understand the performance concerns but does it really
matter for debug output? I believe it is minor compared to the
flexibility it provides for not having a fixed serial port
implementation.

Thanks,
Sunil

On Wed, Mar 01, 2023 at 05:56:36PM +0000, Andrei Warkentin wrote:
> Thanks... let me go a different route.
>
> I'll have 1 more variant that can be used in classical SEC and PEI - only capable of output (input doesn't matter) and rename the one I already shared.  I'll name these SecPeiSerialPortLibRiscVSbi and PrePiDxeSerialPortLibRiscVSbi, respectively.
>
> Does this sound acceptable?
>
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Wednesday, March 1, 2023 11:51 AM
> To: Warkentin, Andrei <andrei.warkentin@intel.com>; devel@edk2.groups.io; kraxel@redhat.com
> Cc: Daniel Schaefer <git@danielschaefer.me>; Sunil V L <sunilvl@ventanamicro.com>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [edk2 2/2] MdePkg: add BaseSerialPortLibRiscVSbi
>
> If a dependency on MdePkg\Include\Library\ BaseRiscVSbiLib.h and SBI services assumed memory is available and code loaded is loaded into RAM and not XIP, then BASE is ok for this component.
>
> You may want to make sure the library class header file and INF file header for BaseRiscVSbiLib describe that environment assumption and the INF for BaseSerialPortLibRiscVSbi also describes that environment assumption.
>
> Mike
>
> > -----Original Message-----
> > From: Warkentin, Andrei <andrei.warkentin@intel.com>
> > Sent: Wednesday, March 1, 2023 9:26 AM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> > devel@edk2.groups.io; kraxel@redhat.com
> > Cc: Daniel Schaefer <git@danielschaefer.me>; Sunil V L
> > <sunilvl@ventanamicro.com>
> > Subject: RE: [edk2-devel] [edk2 2/2] MdePkg: add
> > BaseSerialPortLibRiscVSbi
> >
> > Hi Michael,
> >
> > What module type should I use instead? The reason being this
> > SerialPortLib implementation specifically fits into the class of UEFI
> > implementations, where RAM is always available (initialized by something else prior to Tiano) and non-const globals can be used (e.g. PrePi).
> >
> > A
> >
> > -----Original Message-----
> > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > Sent: Wednesday, March 1, 2023 10:56 AM
> > To: devel@edk2.groups.io; kraxel@redhat.com; Warkentin, Andrei
> > <andrei.warkentin@intel.com>
> > Cc: Daniel Schaefer <git@danielschaefer.me>; Sunil V L
> > <sunilvl@ventanamicro.com>; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Subject: RE: [edk2-devel] [edk2 2/2] MdePkg: add
> > BaseSerialPortLibRiscVSbi
> >
> > Using a global is not compatible with XIP code where only const globals are supported.
> >
> > A module of type BASE is considered compatible with XIP components.
> >
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> > > Hoffmann
> > > Sent: Wednesday, March 1, 2023 1:07 AM
> > > To: Warkentin, Andrei <andrei.warkentin@intel.com>
> > > Cc: devel@edk2.groups.io; Daniel Schaefer <git@danielschaefer.me>;
> > > Sunil V L <sunilvl@ventanamicro.com>
> > > Subject: Re: [edk2-devel] [edk2 2/2] MdePkg: add
> > > BaseSerialPortLibRiscVSbi
> > >
> > > On Wed, Mar 01, 2023 at 08:50:38AM +0000, Warkentin, Andrei wrote:
> > > > The library caller could call Poll() first,
> > >
> > > Ah, Poll is part of the library API, not just an internal helper.
> > > Ok, makes sense then.
> > >
> > > series:
> > > Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> > >
> > > take care,
> > >   Gerd
> > >
> > >
> > >
> > >
> > >
>
>
>
> 
>
>