make PHYS_OFFSET determined at run time (unfinished)

[Ryan Mallon]

jassi brar wrote:
> On Wed, Jan 20, 2010 at 11:39 PM, Steve Chen <schen at mvista.com> wrote:
>> On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
>>> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
>>>> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
>>>>> 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.
>>>> Is there a clean way to pass kernel parameters and machine type from
>>>> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
>>>> needed in ARM startup code.  Just wondering if there is a better way.
>>> u-boot should be doing the right thing, I thought uImage was simply a
>>> zImage wrapped in the right uboot descriptors to tell uboot it was a
>>> kernel and where to load it.
>>>
>>> Certianly uboots i've used can boto zImage just fine.
>> I'm also able to boot zImage under u-boot.  However, I had to set r1
>> manually, and I don't know how to pass kernel parameters (stuff passed
>> into kernel uImage via bootargs) to zImage.  Any tips will be greatly
>> appreciated.
> Perhaps you use 'go' instead of 'bootm' command in u-boot?
> How about:-
> 
>  u-boot # <load zImage at _addr_ by some means>
> 
>  u-boot # setenv machid <your machine ID in hex without the '0x'>
>  u-boot # saveenv //persistently save the machid
>              // now you don't need to set machid even after cold reset
> 
>  u-boot # bootm _addr_
> 
> hth.

The problem is not having something I can boot in U-Boot since users can
always generate their own uImages from an image/zImage. The problem is
that uImages have a fixed load address, so generating a uImage which
contains support for several boards with different load addresses will
be non-bootable on some of those boards.

IMHO, the kernel build scripts shouldn't make it easy to build broken
images. So, either remove the 'make uImage' support (and let users
generate the uImages themselves) or have the build system print a
warning stating that the image will only boot on boards with
PHYS_OFFSET=0xsomething.

~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