From: Tony Lindgren <tony@atomide.com>
To: Sekhar Nori <nsekhar@ti.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"bcousson@baylibre.com" <bcousson@baylibre.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"B, Ravi" <ravibabu@ti.com>
Subject: Re: [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
Date: Wed, 18 Jan 2017 09:39:25 -0800 [thread overview]
Message-ID: <20170118173925.GG7403@atomide.com> (raw)
In-Reply-To: <b586537d-49b6-50a6-ae60-11faf25b26f9@ti.com>
* Sekhar Nori <nsekhar@ti.com> [170118 03:59]:
> Hi Tony,
>
> On Wednesday 18 January 2017 04:57 AM, Tony Lindgren wrote:
> > * B, Ravi <ravibabu@ti.com> [170117 00:15]:
> >> Hi Tony
> >>
> >>> * Ravi Babu <ravibabu@ti.com> [170113 04:41]:
> >>>> The SPL size for DRA74x platform has increased and is now more than
> >>>> 64KB. Increase QSPI SPL partition size to 256KB for DRA74x EVM.
> >>>>
> >>>> QSPI partition numbering changes because of this.
> >>
> >>> And this will break the existing partitions potentially..
> >>> See what was discussed on the list few days ago in thread "[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table".
> >>
> >>> It's best to have these left empty or as they originally were and let u-boot configure the partitions.
> >>
> >> Agree with you. For dra7xx platform the SPL size has been increased to 256KB and hence the existing QSPI SPL partition in kernel (64K size) will break when latest mainline u-boot is used.
> >> Here only SPL partition has been changed and other partition & size is NOT changed and kept intact. I feel it will not break the existing partitions for dra7xx platform.
> >
> > What about the renumbering of partitions in your patch?
>
> Thats true, partitions will get renumbered. But mtd numbering can change
> depending on probe order of devices anyway. So usespace which uses
> hardcoded mtd partition numbers is pretty fragile already, I guess.
>
> >
> > Probably just best to make the partition information empty in the
> > kernel as discussed.
>
> Given that existing dtbs already have the partition information, wont
> this be treated as a regression for someone upgrading to new kernel?
Well these "flag day" type changes are not acceptable because they are
impossible to coordinate. You can't assume people update their bootloader
on regular basis, or update both bootloader and kernel to some specific
versions.
> Going forward, is the preference that new boards shall not have
> partition information in DT?
Yes or else it will have to stay as it was originally set because
of these issues.
Regards,
Tony
next prev parent reply other threads:[~2017-01-18 17:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 12:40 [PATCH 0/2] dra7x: dts update for increase in QSPI SPL parttion size Ravi Babu
[not found] ` <1484311234-21978-1-git-send-email-ravibabu-l0cyMroinI0@public.gmane.org>
2017-01-13 12:40 ` [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size Ravi Babu
2017-01-13 18:12 ` Tony Lindgren
2017-01-17 8:14 ` B, Ravi
2017-01-17 23:27 ` Tony Lindgren
2017-01-18 11:58 ` Sekhar Nori
2017-01-18 17:39 ` Tony Lindgren [this message]
2017-01-13 12:40 ` [PATCH 2/2] ARM: dts: dra72x-evm: " Ravi Babu
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=20170118173925.GG7403@atomide.com \
--to=tony@atomide.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=ravibabu@ti.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;
as well as URLs for NNTP newsgroup(s).