From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
Date: Sat, 22 Nov 2014 21:56:48 +0100 [thread overview]
Message-ID: <20141122215648.771225f2@free-electrons.com> (raw)
In-Reply-To: <20141121172031.GC20238@lunn.ch>
Dear Andrew Lunn,
On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > Is this a well defined mechanism supported by mainline uboot, barebox
> > > etc. Or is it some Marvell extension to their uboot?
> >
> > As far as I know, it is a Marvell extension to their "binary header",
> > so it's done even before U-Boot starts.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No, it is not the BootROM that does this. It is the binary header,
which is something different.
Essentially, the boot process is the following:
* BootROM runs. This one cannot be changed, it is set in stone in the
chip.
* It locates a bootable image from some media, and looks at its
header. Its header can contain several sections, some describing
some (address, value) pairs to write some values to some registers
(this was used on Kirkwood to configure the memory controller, for
example). Some other sections can contain binary code that will get
executed on the SoC, this is what is called a "binary header". It
gets executed before U-Boot starts, but it's really a piece of
software that can be changed.
* Then it loads and runs U-Boot.
The "binary header" is currently the piece of code that we extract
using the kwbimage tool from existing U-Boot images to build working
Barebox images, since we haven't yet written the equivalent code in
Barebox land.
So, the specification of where the "resume informations" is located and
how this information is organized is purely defined by software that
can potentially be changed, not by the BootROM. Though that if we
decided to use a different protocol, we would basically have a
suspend/resume in the kernel that would not work with any Marvell
platform that uses the default bootloader.
I hope that this clarifies how things are working.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Gregory Clement
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Nadav Haklai <nadavh-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
Ezequiel Garcia
<ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
Date: Sat, 22 Nov 2014 21:56:48 +0100 [thread overview]
Message-ID: <20141122215648.771225f2@free-electrons.com> (raw)
In-Reply-To: <20141121172031.GC20238-g2DYL2Zd6BY@public.gmane.org>
Dear Andrew Lunn,
On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > Is this a well defined mechanism supported by mainline uboot, barebox
> > > etc. Or is it some Marvell extension to their uboot?
> >
> > As far as I know, it is a Marvell extension to their "binary header",
> > so it's done even before U-Boot starts.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No, it is not the BootROM that does this. It is the binary header,
which is something different.
Essentially, the boot process is the following:
* BootROM runs. This one cannot be changed, it is set in stone in the
chip.
* It locates a bootable image from some media, and looks at its
header. Its header can contain several sections, some describing
some (address, value) pairs to write some values to some registers
(this was used on Kirkwood to configure the memory controller, for
example). Some other sections can contain binary code that will get
executed on the SoC, this is what is called a "binary header". It
gets executed before U-Boot starts, but it's really a piece of
software that can be changed.
* Then it loads and runs U-Boot.
The "binary header" is currently the piece of code that we extract
using the kwbimage tool from existing U-Boot images to build working
Barebox images, since we haven't yet written the equivalent code in
Barebox land.
So, the specification of where the "resume informations" is located and
how this information is organized is purely defined by software that
can potentially be changed, not by the BootROM. Though that if we
decided to use a different protocol, we would basically have a
suspend/resume in the kernel that would not work with any Marvell
platform that uses the default bootloader.
I hope that this clarifies how things are working.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-11-22 20:56 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 15:59 [PATCHv3 00/16] Suspend to RAM support for Armada XP Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-21 15:59 ` [PATCHv3 01/16] Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-21 15:59 ` [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-22 0:53 ` Jason Cooper
2014-11-22 0:53 ` Jason Cooper
2014-11-25 17:44 ` Thomas Petazzoni
2014-11-25 17:44 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 03/16] irqchip: irq-armada-370-xp: suspend/resume support Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 04/16] clocksource: time-armada-370-xp: add " Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 05/16] gpio: mvebu: " Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-28 11:55 ` Linus Walleij
2014-11-28 11:55 ` Linus Walleij
2014-11-21 16:00 ` [PATCHv3 06/16] bus: mvebu-mbus: " Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 07/16] bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-26 4:03 ` Jason Cooper
2014-11-26 4:03 ` Jason Cooper
2014-11-26 4:03 ` Jason Cooper
2014-11-21 16:00 ` [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:41 ` Andrew Lunn
2014-11-21 16:41 ` Andrew Lunn
2014-11-21 16:59 ` Thomas Petazzoni
2014-11-21 16:59 ` Thomas Petazzoni
2014-11-21 17:20 ` Andrew Lunn
2014-11-21 17:20 ` Andrew Lunn
2014-11-22 0:50 ` Jason Cooper
2014-11-22 0:50 ` Jason Cooper
2014-11-22 20:56 ` Thomas Petazzoni [this message]
2014-11-22 20:56 ` Thomas Petazzoni
2014-11-23 3:36 ` Andrew Lunn
2014-11-23 3:36 ` Andrew Lunn
2014-11-25 6:51 ` Thomas Petazzoni
2014-11-25 6:51 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 10/16] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 11/16] ARM: mvebu: Armada XP GP specific suspend/resume code Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 12/16] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 13/16] ARM: mvebu: synchronize secondary CPU clocks on resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 14/16] ARM: mvebu: add suspend/resume DT information for Armada XP GP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 15/16] ARM: mvebu: adjust mbus controller description on Armada 370/XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 16/16] ARM: mvebu: add SDRAM controller description for Armada XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-22 1:44 ` [PATCHv3 00/16] Suspend to RAM support " Jason Cooper
2014-11-22 1:44 ` Jason Cooper
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=20141122215648.771225f2@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.