From: "Marek Behún" <marek.behun@nic.cz>
To: "Pali Rohár" <pali@kernel.org>
Cc: Stefan Roese <sr@denx.de>, u-boot@lists.denx.de
Subject: Re: [PATCH u-boot-mvebu 2/3] arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space
Date: Tue, 15 Feb 2022 14:20:12 +0100 [thread overview]
Message-ID: <20220215142012.36b3d2a2@dellmb> (raw)
In-Reply-To: <20220215141517.0ffed9d6@dellmb>
On Tue, 15 Feb 2022 14:15:17 +0100
Marek Behún <marek.behun@nic.cz> wrote:
> > In _production version_ where is no debug capability and no access to
> > any memory (just ability to boot) is is probably not needed, but none of
> > A3720 board is building this kind of version (by default). And in case
> > BootROM is mapped also in these versions, is there any issue with it?
>
> My issue is that it isn't needed. You can just dump it once, publish it
> somewhere, and you are done. No need to keep that window mapped for
> everyone else.
BTW, I can imagine situation where mapping BootROM code can be useful.
For example if the BootROM code contains some cryptographic functions
(which are necessary for secure boot) and you know where they are and
their type, so you can use them if you want to save space in your own
code.
But mapping BootROM so that everyone, if they want, can dump it, is
unnecessary IMO, because you can simply do it once and then you have
the code.
Keep in mind that this is my opinion. If Stefan agrees with you, I have
no issue with merging this.
Marek
next prev parent reply other threads:[~2022-02-15 13:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 23:28 [PATCH u-boot-mvebu 0/3] arm: mvebu: a37xx: Fix and extend building memory map Pali Rohár
2022-02-14 23:28 ` [PATCH u-boot-mvebu 1/3] arm: mvebu: a37xx: Fix calling build_mem_map() Pali Rohár
2022-02-15 11:09 ` Stefan Roese
2022-02-15 13:15 ` Marek Behún
2022-02-14 23:28 ` [PATCH u-boot-mvebu 2/3] arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space Pali Rohár
2022-02-15 12:11 ` Marek Behún
2022-02-15 13:04 ` Pali Rohár
2022-02-15 13:15 ` Marek Behún
2022-02-15 13:20 ` Marek Behún [this message]
2022-02-16 8:55 ` Stefan Roese
2022-02-16 9:45 ` Pali Rohár
2022-02-16 8:56 ` Stefan Roese
2022-02-14 23:28 ` [PATCH u-boot-mvebu 3/3] arm: mvebu: a37xx: Fix comment with name of the function Pali Rohár
2022-02-15 13:15 ` Marek Behún
2022-02-16 8:57 ` Stefan Roese
2022-02-16 10:18 ` [PATCH u-boot-mvebu v2 0/3] arm: mvebu: a37xx: Fix and extend building memory map Pali Rohár
2022-02-16 10:18 ` [PATCH u-boot-mvebu v2 1/3] arm: mvebu: a37xx: Fix calling build_mem_map() Pali Rohár
2022-02-16 10:18 ` [PATCH u-boot-mvebu v2 2/3] arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space Pali Rohár
2022-02-16 10:24 ` Stefan Roese
2022-02-16 10:18 ` [PATCH u-boot-mvebu v2 3/3] arm: mvebu: a37xx: Fix comment with name of the function Pali Rohár
2022-02-17 15:38 ` [PATCH u-boot-mvebu v2 0/3] arm: mvebu: a37xx: Fix and extend building memory map Stefan Roese
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-all 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=20220215142012.36b3d2a2@dellmb \
--to=marek.behun@nic.cz \
--cc=pali@kernel.org \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/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