From: "levi.yun" <yeoreum.yun@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>, devel@edk2.groups.io
Cc: sami.mujawar@arm.com, ray.ni@intel.com, pierre.gondois@arm.com,
nd@arm.com
Subject: Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: Initialise serial port early in StandaloneMmEntryPoint
Date: Fri, 5 Jan 2024 17:22:49 +0000 [thread overview]
Message-ID: <5a07db2b-ea25-495d-91f8-7b51ddd9ec75@arm.com> (raw)
In-Reply-To: <CAMj1kXE6KiOtVpdCvzKgJ0JYAAjPHUejzVbT3DO8QuRN6BH4iw@mail.gmail.com>
Hi Ard :)
> So now we will always initialize the serial port in the entrypoint
> only because DebugLib might use it later with doing the
> initialization.
>
> That doesn't sound quite correct to me.
>
> Could you explain why we cannot rely on DebugLib to call the
> initializer / constructor at the right time?
Because, DebugLib constructor which use serial port is called in
StandAloneMmMain function.
But, this constrcutor is in _ModuleEntryPoint in StandAloneMmCoreEntry.
That means all DEBUG used in _ModuleEntryPoint can use uninitialized
serial port.
one of typical example is GetSpmVersion function.
_ModuleEntryPoint (in StandAloneMmCoreEntry)
// Hazard Area start
GetSpmVersion
DEBUG (DEBUG_INFO, xxx) // It could be use uninitalized
Serial port.
...
// Hazard Area end
ProcessModuleEntryPointList (StandAloneMmMain)
ProcessLibraryConstructorList // Here. call DebugLib
constructor with SerialPortIntialize
When you see above, I would be clear. between Hazard Area Start to
Hazard Area End.
DEBUG macro would use uninitailized Serial port if that's not
initialized by TF-A.
So, It should be call SerialPortInitialized at the _ModuleEntryPoint.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113313): https://edk2.groups.io/g/devel/message/113313
Mute This Topic: https://groups.io/mt/103540969/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2024-01-05 17:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 11:49 [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: Initialise serial port early in StandaloneMmEntryPoint levi.yun
2024-01-05 11:52 ` levi.yun
2024-01-05 16:46 ` Ard Biesheuvel
2024-01-05 17:22 ` levi.yun [this message]
2024-01-05 18:38 ` Oliver Smith-Denny
2024-01-08 12:16 ` Laszlo Ersek
2024-01-10 16:13 ` levi.yun
2024-01-10 16:41 ` Laszlo Ersek
2024-01-10 17:16 ` levi.yun
2024-01-10 21:06 ` Brian J. Johnson
2024-01-11 9:05 ` levi.yun
[not found] ` <17A93FAECCFD3533.4530@groups.io>
2024-01-18 10:19 ` levi.yun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a07db2b-ea25-495d-91f8-7b51ddd9ec75@arm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox