public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	uboot-imx@nxp.com, Peng Fan <peng.fan@nxp.com>
Cc: Fabio Estevam <festevam@gmail.com>, sbabic@denx.de, u-boot@lists.denx.de
Subject: Re: [PATCH V2] cpu: imx8_cpu: Avoid revision to corrupt device tree
Date: Thu, 17 Oct 2024 08:25:40 -0600	[thread overview]
Message-ID: <20241017142540.GK4959@bill-the-cat> (raw)
In-Reply-To: <CAOMZO5Aikd3f5-Cnbtcn74qBAkLOs5hv_42FeZk2nxz94vksBg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Thu, Oct 17, 2024 at 09:50:22AM -0300, Fabio Estevam wrote:
> On Thu, Oct 17, 2024 at 4:08 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> 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.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >
> > V2:
> >  move the rev to malloc area in cpu_imx_plat
> >  tested on i.MX8MP EVK
> 
> Please adapt the commit log to include this information.
> 
> This patch breaks CI. Make sure to run all your patches through CI:
> 
> https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/920875
> 
> aarch64: + imx8qm_rom7720_a1_4G
> 321+WARNING 'mx8qm-ahab-container.img' not found, resulting binary is
> not-functional
> 322+drivers/cpu/imx8_cpu.c: In function 'get_imx_rev_str':
> 323+drivers/cpu/imx8_cpu.c:78:17: error: 'rev' is used uninitialized
> [-Werror=uninitialized]
> 324+ 78 | switch (rev) {
> 325+ | ^~~~~~
> 326+drivers/cpu/imx8_cpu.c:76:22: note: 'rev' was declared here
> 327+ 76 | char rev;
> 328+ | ^~~
> 329+cc1: all warnings being treated as errors
> 
> I am getting too much extra work to process the patches from NXP folks
> and I am not happy with it.

Azure can be slow, yes, but I would expect NXP to be able to setup their
own internal GitLab instance and runners, or paid Azure setup, or even
just use your own GitHub account and then own Azure account and not be
using the shared free pool of runners.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-10-17 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17  8:12 [PATCH V2] cpu: imx8_cpu: Avoid revision to corrupt device tree Peng Fan (OSS)
2024-10-17  9:19 ` Lothar Waßmann
2024-10-17  9:21   ` Peng Fan
2024-10-17 11:25     ` Lothar Waßmann
2024-10-17 12:50 ` Fabio Estevam
2024-10-17 14:25   ` Tom Rini [this message]
2024-10-18  1:02   ` Peng Fan

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=20241017142540.GK4959@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=festevam@gmail.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