From: Sascha Hauer <s.hauer@pengutronix.de>
To: Michael Burkey <mdburkey@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: Porting barebox (devicetree) to Variscite iMX6 SOM
Date: Thu, 16 Jan 2014 15:13:22 +0100 [thread overview]
Message-ID: <20140116141322.GX16215@pengutronix.de> (raw)
In-Reply-To: <CAJyuEefMzkW4mCfe+iR7FfVv6jeQMS3XuoPFtO3E8zNomecKoA@mail.gmail.com>
On Wed, Jan 15, 2014 at 01:35:15PM -0500, Michael Burkey wrote:
> Sascha, thanks for the advice on the stack unwinding and other
> debugging aids. It was a huge help.
>
> I have made progress and isolated and gotten past my earlier null
> pointer problem -- it turned out to be an issue that you had already
> fixed on the tip (the recent changes to armlinux_get_bootparams fixed
> the null pointer issue).
>
> That said, I'm still having issues booting with an older kernel. Which
> brings me to my next question....
>
> In the case where I am booting an old, non-devicetree, kernel with a
> newer, devicetree, version of barebox, and then using "oftree -f" to
> flush the devicetree before starting the kernel, what is the proper
> way to have things like the boot parameters, the boot architecture,
> etc. specified for passing to the older kernel? Just go back and add
> them into the board files like they used to be in older versions of
> barebox?
yes.
> Do you know if having stuff specified in both the old way and
> in the oftree will cause any potential problems?
Not sure if I understand you. The kernel either takes old style ATAGs or
a devicetree (in the same pointer), barebox sets up either one or the
other, but never both. The machine number becomes meaningless with
devicetree support, it doesn't matter if it is specified or not.
>
> Basically, my goal is to have a version of barebox than can launch
> either our current (old) kernel or a newer mainline version
> interchangeably without having to upgrade barebox (basically, we will
> probably initially be shipping an older kernel and then upgrading to a
> newer one later -- and, if at all possible, I'd really rather not have
> to incur the risk of having our users need to update barebox in the
> field as well).
Basically barebox has to know whether a kernel is to be started with
devicetree or not, which means you have to have two boot entries, one
with devicetree and one without. There are two ways around it:
- Use bootloader spec based booting. This way you have text files on
your boot medium describing what to boot. This text file would
include information whether or not a kernel should be booted with
devicetree
- Use appended devicetrees: cat zImage dtb > myImage. Such a kernel
can be started the traditional way and still uses devicetree.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-01-16 14:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 17:07 Michael Burkey
2013-12-11 23:17 ` Alexander Aring
2013-12-12 8:04 ` Sascha Hauer
2013-12-12 18:49 ` Michael Burkey
2013-12-12 18:56 ` Michael Burkey
2013-12-12 19:12 ` Alexander Aring
2013-12-12 19:24 ` Michael Burkey
2013-12-12 19:58 ` Sascha Hauer
2013-12-12 22:44 ` Michael Burkey
2013-12-18 16:39 ` Michael Burkey
2013-12-18 21:34 ` Michael Burkey
2013-12-19 8:09 ` Sascha Hauer
2014-01-09 7:20 ` Michael Burkey
2014-01-09 19:59 ` Michael Burkey
2014-01-10 8:00 ` Sascha Hauer
2014-01-10 8:13 ` Sascha Hauer
2014-01-15 18:35 ` Michael Burkey
2014-01-16 14:13 ` Sascha Hauer [this message]
2014-01-16 21:18 ` Michael Burkey
2014-01-20 8:00 ` Sascha Hauer
2014-01-29 21:10 ` Michael Burkey
2014-01-29 21:53 ` Michael Burkey
2014-02-01 18:35 ` Sascha Hauer
2014-02-04 21:44 ` Michael D. Burkey
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=20140116141322.GX16215@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=mdburkey@gmail.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