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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.