From: Tom Rini <trini@konsulko.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
"festevam@gmail.com" <festevam@gmail.com>,
"sbabic@denx.de" <sbabic@denx.de>,
"u-boot@lists.denx.de" <u-boot@lists.denx.de>,
dl-uboot-imx <uboot-imx@nxp.com>,
Gilles Talis <gilles.talis@nxp.com>
Subject: Re: [PATCH] cpu: imx8_cpu: Avoid revision to corrupt device tree
Date: Wed, 16 Oct 2024 21:45:07 -0600 [thread overview]
Message-ID: <20241017034507.GJ4959@bill-the-cat> (raw)
In-Reply-To: <PAXPR04MB845984549FD1762C0A3AC90888472@PAXPR04MB8459.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]
On Thu, Oct 17, 2024 at 03:14:46AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH] cpu: imx8_cpu: Avoid revision to corrupt device
> > tree
> >
> > On Fri, Oct 11, 2024 at 06:58:27PM +0800, Peng Fan (OSS) wrote:
> >
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > U-Boot device tree is padded just after U-Boot proper. After the
> > whole
> > > stuff loaded to DRAM space, the device tree area is conflict with BSS
> > > region before U-Boot relocation. So any write to BSS area before
> > > reloc_fdt will corrupt the device tree. Without the fix, there is
> > > issue that “binman_init failed:-2” on i.MX8MP-EVK board.
> > >
> > > Move the variable to data section to fix the issue
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/cpu/imx8_cpu.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/cpu/imx8_cpu.c b/drivers/cpu/imx8_cpu.c index
> > > 6c0a8c0cbe4..19c65c7ce47 100644
> > > --- a/drivers/cpu/imx8_cpu.c
> > > +++ b/drivers/cpu/imx8_cpu.c
> > > @@ -71,7 +71,7 @@ static const char *get_imx_type_str(u32
> > imxtype)
> > >
> > > static const char *get_imx_rev_str(u32 rev) {
> > > - static char revision[4];
> > > + static char revision[4] __section(".data");
> >
> > After my last mail, I pulled up the patch itself and started looking at the
> > driver. Why is "revision" being done like this? This is not a good
> > common practice.
>
> Since the function returns a pointer to a string, so ...
> We could move it to malloc area.
Yes, something like that sounds better, thanks.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2024-10-17 3:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 10:58 [PATCH] cpu: imx8_cpu: Avoid revision to corrupt device tree Peng Fan (OSS)
2024-10-11 16:56 ` Tom Rini
2024-10-11 18:06 ` Fabio Estevam
2024-10-12 0:16 ` Peng Fan
2024-10-16 18:45 ` Tom Rini
2024-10-17 1:10 ` Peng Fan
2024-10-17 3:05 ` Tom Rini
2024-10-17 3:07 ` Peng Fan
2024-10-16 18:22 ` Fabio Estevam
2024-10-17 3:11 ` Tom Rini
2024-10-17 3:14 ` Peng Fan
2024-10-17 3:45 ` Tom Rini [this message]
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=20241017034507.GJ4959@bill-the-cat \
--to=trini@konsulko.com \
--cc=festevam@gmail.com \
--cc=gilles.talis@nxp.com \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=sbabic@denx.de \
--cc=u-boot@lists.denx.de \
--cc=uboot-imx@nxp.com \
/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