From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1] arm: socfpga: Enable load zImage and Linux DTB from QSPI
Date: Fri, 27 Nov 2015 13:11:02 +0100 [thread overview]
Message-ID: <201511271311.02266.marex@denx.de> (raw)
In-Reply-To: <1448626043.2125.3.camel@altera.com>
On Friday, November 27, 2015 at 01:07:23 PM, Chin Liang See wrote:
> On Fri, 2015-11-27 at 11:20 +0100, Marek Vasut wrote:
> > On Friday, November 27, 2015 at 02:34:27 AM, Chin Liang See wrote:
> > > Hi Marek,
> > >
> > > On Fri, 2015-11-27 at 02:27 +0100, Marek Vasut wrote:
> > > > On Friday, November 27, 2015 at 02:24:49 AM, Chin Liang See
> > > >
> > > > wrote:
> > > > > Hi Pavel,
> > > > >
> > > > > On Thu, 2015-11-26 at 15:43 +0100, Pavel Machek wrote:
> > > > > > Hi!
> > > > > >
> > > > > > > Adding new environment qspiload which will load zImage and
> > > > > > > Linux DTB from serial NOR flash. The default flash offset
> > > > > > > for
> > > > > > > the images as below and they are configurable during run
> > > > > > > time.
> > > > > > >
> > > > > > > - zImage located at 0xa0000 with assuming file size 6MB
> > > > > > > - Linux DTB located at 0x50000 with assuming file size 28kB
> > > > > >
> > > > > > Hmm. Ok, zImage second, so that it can grow. Makes sense. Not
> > > > > > sure if
> > > > > > 28kB is not a bit small for DTB. I'd reserve at least 64kB.
> > > > >
> > > > > Yup, it can grow up to 64kB as the size for a sector. We used
> > > > > 28KB
> > > > > mainly for boot time performance.
> > > >
> > > > So why don't you use UBI on the QSPI NOR ? That way, you'd secure
> > > > the
> > > > binaries against bitrot as well.
> > >
> > > Good point. Its a nice enhancement as we were using raw access for
> > > the
> > > images in NAND and QSPI. Will add a new command for fs support once
> > > we
> > > enable the ubifs support in socfpga
> >
> > Why can't this be enabled now then ?
>
> Mainly for backward compatibility as customer might have their own
> script on programming a blank flash in production. This is the same
> where we can do mmc load or a load (with file system).
Does that imply that we will have to get stuck in the past because some
random customer of some random company might have a random script somewhere? :)
Best regards,
Marek Vasut
next prev parent reply other threads:[~2015-11-27 12:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-26 2:32 [U-Boot] [PATCH v1] arm: socfpga: Enable load zImage and Linux DTB from QSPI Chin Liang See
2015-11-26 6:12 ` Stefan Roese
2015-11-27 1:26 ` Chin Liang See
2015-11-26 14:43 ` Pavel Machek
2015-11-27 1:24 ` Chin Liang See
2015-11-27 1:27 ` Marek Vasut
2015-11-27 1:34 ` Chin Liang See
2015-11-27 10:20 ` Marek Vasut
2015-11-27 12:07 ` Chin Liang See
2015-11-27 12:11 ` Marek Vasut [this message]
2015-11-27 12:16 ` Chin Liang See
2015-11-27 12:26 ` Marek Vasut
2015-11-27 13:08 ` Chin Liang See
2015-11-27 14:24 ` Marek Vasut
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=201511271311.02266.marex@denx.de \
--to=marex@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