From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: make PHYS_OFFSET determined at run time (unfinished)
Date: Wed, 20 Jan 2010 00:55:06 +0000 [thread overview]
Message-ID: <20100120005505.GD26562@trinity.fluff.org> (raw)
In-Reply-To: <4B561581.6060400@bluewatersys.com>
On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> Uwe Kleine-K?nig wrote:
> > Hello,
> >
> > I'm looking into making PHYS_OFFSET determined at run time. I saw a
> > patch for it that already made it a few times on the list[1].
> >
> > I'm not yet done, but first want to announce that I look into that to
> > prevent duplicate work---so if you intended to do the same let's look
> > together---and to post some clean up patches that are the result up to
> > now of my digging in the boot code.
> >
> > I will send now three patches in reply to this mail, and later hopefully
> > more.
> >
> > Best regards
> > Uwe
> >
> > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> >
>
> One of the problems that got brought up previously was the 'make uImage'
> can end up generating unbootable images with runtime PHYS_OFFSET. The
> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> uImage's need to have a fixed load address encoded.
>
> As I stated in the previous thread, this is _not_ a kernel issue,
> however it is no good having a kernel which contains support for two
> boards which boot from different address and then generating a uImage
> which can only boot on one of them without warning the user about this
> problem. Otherwise you are going to start getting "I did make uImage and
> my board won't boot" problems.
>
> There are a few solutions to this problem:
> 1) Drop uImage make support and require users generate them manually.
> 2) Have a uImage offset config option to allow uImage users to specify
> what they want the load address to be. See:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> 3) Print an error if "make uImage" is run for a kernel which has more
> than one boot address (possible?)
> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> however a number of people are still using older U-Boots.
Or of course, boot zImages. I belive u-boot has support for zImage.
>
> ~Ryan
>
> --
> Bluewater Systems Ltd - ARM Technology Solution Centre
>
> Ryan Mallon 5 Amuri Park, 404 Barbadoes St
> ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
> http://www.bluewatersys.com New Zealand
> Phone: +64 3 3779127 Freecall: Australia 1800 148 751
> Fax: +64 3 3779135 USA 1800 261 2934
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2010-01-20 0:55 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 8:38 make PHYS_OFFSET determined at run time (unfinished) Uwe Kleine-König
2010-01-19 8:43 ` [PATCH] arm: don't define unused symbol initrd_phys for zImage Uwe Kleine-König
2010-01-19 8:43 ` [PATCH] arm: add a comment to __atags_pointer describing where it's set Uwe Kleine-König
2010-01-19 8:52 ` Russell King - ARM Linux
2010-01-19 8:43 ` [PATCH] arm: remove support for old way to pass kernel parameters Uwe Kleine-König
2010-01-19 8:54 ` Russell King - ARM Linux
2010-01-19 9:13 ` [PATCH] arm: deprecate " Uwe Kleine-König
2010-01-19 20:26 ` make PHYS_OFFSET determined at run time (unfinished) Ryan Mallon
2010-01-20 0:55 ` Ben Dooks [this message]
2010-01-20 2:21 ` Steve Chen
2010-01-20 2:32 ` Ben Dooks
2010-01-20 14:39 ` Steve Chen
2010-01-20 14:43 ` Uwe Kleine-König
2010-01-21 1:28 ` jassi brar
2010-01-21 2:15 ` Ryan Mallon
2010-01-21 11:57 ` Steve Chen
2010-01-21 12:48 ` Steve Chen
2010-01-21 11:43 ` Steve Chen
2010-01-21 12:43 ` Uwe Kleine-König
2010-01-21 15:22 ` Steve Chen
2010-01-22 12:32 ` jassi brar
2010-01-20 9:53 ` Russell King - ARM Linux
2010-01-20 8:38 ` Uwe Kleine-König
2010-01-22 11:58 ` Uwe Kleine-König
2010-01-25 17:32 ` change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)] Uwe Kleine-König
2010-01-25 19:32 ` Ryan Mallon
2010-01-30 21:02 ` Uwe Kleine-König
2010-01-30 21:07 ` [PATCH 1/3] zImage: don't hard code the stack size twice Uwe Kleine-König
2010-01-30 21:07 ` [PATCH 2/3] uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET Uwe Kleine-König
2010-01-30 21:07 ` [PATCH 3/3] Allow PHYS_OFFSET to be runtime determined Uwe Kleine-König
2010-02-04 9:51 ` change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)] Uwe Kleine-König
2010-02-04 9:52 ` [PATCH] arm: remove bit-rotten STANDALONE_DEBUG for decompressor Uwe Kleine-König
2010-02-12 11:03 ` [PULL REQUEST] runtime physoffset [Was: change boot requirements] Uwe Kleine-König
2010-03-08 12:15 ` Amit Kucheria
2010-03-22 21:09 ` Uwe Kleine-König
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=20100120005505.GD26562@trinity.fluff.org \
--to=ben-linux@fluff.org \
--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 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).