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 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.