booting single uImage on platforms with different base addresses for SDRAM

booting single uImage on platforms with different base addresses for SDRAM

[Peter De Schrijver]

Hi,

Currently uImages have the load address hardcoded. As we now try to support
as many ARM platforms as possible with a single binary, this becomes a
problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
starts at 0x80000000. It's possible to build a kernel image which can deal
with this, but the uImage still uses a hardcoded address. This results
in requiring 2 different uImages even though the zImage is the same.

Has anyone thought of a solution to this problem?

Thanks,

Peter.

[U-Boot] booting single uImage on platforms with different base addresses for SDRAM

[Peter De Schrijver]

Hi,

Currently uImages have the load address hardcoded. As we now try to support
as many ARM platforms as possible with a single binary, this becomes a
problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
starts at 0x80000000. It's possible to build a kernel image which can deal
with this, but the uImage still uses a hardcoded address. This results
in requiring 2 different uImages even though the zImage is the same.

Has anyone thought of a solution to this problem?

Thanks,

Peter.

booting single uImage on platforms with different base addresses for SDRAM

[Russell King - ARM Linux]

On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> Currently uImages have the load address hardcoded. As we now try to support
> as many ARM platforms as possible with a single binary, this becomes a
> problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> starts at 0x80000000. It's possible to build a kernel image which can deal
> with this, but the uImage still uses a hardcoded address. This results
> in requiring 2 different uImages even though the zImage is the same.

This is a problem with the uImage format.  It can only be fixed in uboot
- it's not a kernel problem.

> Has anyone thought of a solution to this problem?

There was talk about making '0' or something a special address, and
fixing uboot to place it appropriately (in much the same way that the
other boot loaders such as blob's offset from the start of RAM, or
redboot's scripted loading which takes the load address.)

[U-Boot] booting single uImage on platforms with different base addresses for SDRAM

[Russell King - ARM Linux]

On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> Currently uImages have the load address hardcoded. As we now try to support
> as many ARM platforms as possible with a single binary, this becomes a
> problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> starts at 0x80000000. It's possible to build a kernel image which can deal
> with this, but the uImage still uses a hardcoded address. This results
> in requiring 2 different uImages even though the zImage is the same.

This is a problem with the uImage format.  It can only be fixed in uboot
- it's not a kernel problem.

> Has anyone thought of a solution to this problem?

There was talk about making '0' or something a special address, and
fixing uboot to place it appropriately (in much the same way that the
other boot loaders such as blob's offset from the start of RAM, or
redboot's scripted loading which takes the load address.)

booting single uImage on platforms with different base addresses for SDRAM

[Nicolas Pitre]

On Thu, 22 Sep 2011, Russell King - ARM Linux wrote:

> On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> > Currently uImages have the load address hardcoded. As we now try to support
> > as many ARM platforms as possible with a single binary, this becomes a
> > problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> > starts at 0x80000000. It's possible to build a kernel image which can deal
> > with this, but the uImage still uses a hardcoded address. This results
> > in requiring 2 different uImages even though the zImage is the same.
> 
> This is a problem with the uImage format.  It can only be fixed in uboot
> - it's not a kernel problem.
> 
> > Has anyone thought of a solution to this problem?
> 
> There was talk about making '0' or something a special address, and
> fixing uboot to place it appropriately (in much the same way that the
> other boot loaders such as blob's offset from the start of RAM, or
> redboot's scripted loading which takes the load address.)

... or make u-Boot support plain zImage on ARM (like it apparently does 
for MIPS).  The u-Boot load command can accept a destination memory 
address just fine, but u-Boot always insists on relocating it when it is 
a uImage.


Nicolas

[U-Boot] booting single uImage on platforms with different base addresses for SDRAM

[Nicolas Pitre]

On Thu, 22 Sep 2011, Russell King - ARM Linux wrote:

> On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> > Currently uImages have the load address hardcoded. As we now try to support
> > as many ARM platforms as possible with a single binary, this becomes a
> > problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> > starts at 0x80000000. It's possible to build a kernel image which can deal
> > with this, but the uImage still uses a hardcoded address. This results
> > in requiring 2 different uImages even though the zImage is the same.
> 
> This is a problem with the uImage format.  It can only be fixed in uboot
> - it's not a kernel problem.
> 
> > Has anyone thought of a solution to this problem?
> 
> There was talk about making '0' or something a special address, and
> fixing uboot to place it appropriately (in much the same way that the
> other boot loaders such as blob's offset from the start of RAM, or
> redboot's scripted loading which takes the load address.)

... or make u-Boot support plain zImage on ARM (like it apparently does 
for MIPS).  The u-Boot load command can accept a destination memory 
address just fine, but u-Boot always insists on relocating it when it is 
a uImage.


Nicolas

[U-Boot] booting single uImage on platforms with different base addresses for SDRAM

[Steve Chen]

On Thu, Sep 22, 2011 at 7:57 AM, Nicolas Pitre <nico@fluxnic.net> wrote:

> On Thu, 22 Sep 2011, Russell King - ARM Linux wrote:
>
> > On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> > > Currently uImages have the load address hardcoded. As we now try to
> support
> > > as many ARM platforms as possible with a single binary, this becomes a
> > > problem. On tegra20 SDRAM starts at physical address 0, but on tegra30
> SDRAM
> > > starts at 0x80000000. It's possible to build a kernel image which can
> deal
> > > with this, but the uImage still uses a hardcoded address. This results
> > > in requiring 2 different uImages even though the zImage is the same.
> >
> > This is a problem with the uImage format.  It can only be fixed in uboot
> > - it's not a kernel problem.
> >
> > > Has anyone thought of a solution to this problem?
> >
> > There was talk about making '0' or something a special address, and
> > fixing uboot to place it appropriately (in much the same way that the
> > other boot loaders such as blob's offset from the start of RAM, or
> > redboot's scripted loading which takes the load address.)
>
> ... or make u-Boot support plain zImage on ARM (like it apparently does
> for MIPS).  The u-Boot load command can accept a destination memory
> address just fine, but u-Boot always insists on relocating it when it is
> a uImage.
>
>
Also, check out this thread.

http://comments.gmane.org/gmane.linux.ports.arm.kernel/95030

You may find it useful as a reference.

Regards,

Steve

booting single uImage on platforms with different base addresses for SDRAM

[Wolfgang Denk]

Dear Peter De Schrijver,

In message <20110922110411.GD20444@tbergstrom-lnx.Nvidia.com> you wrote:
> Hi,
> 
> Currently uImages have the load address hardcoded. As we now try to support
> as many ARM platforms as possible with a single binary, this becomes a
> problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> starts at 0x80000000. It's possible to build a kernel image which can deal
> with this, but the uImage still uses a hardcoded address. This results
> in requiring 2 different uImages even though the zImage is the same.
> 
> Has anyone thought of a solution to this problem?

Yes, this has been discussed before.  I proposed to allow for an
offset specification instead of an absolute address.  After that, the
discussions faded.  No code has been submitted yet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Never give in.  Never give in.  Never. Never. Never."
- Winston Churchill

[U-Boot] booting single uImage on platforms with different base addresses for SDRAM

[Wolfgang Denk]

Dear Peter De Schrijver,

In message <20110922110411.GD20444@tbergstrom-lnx.Nvidia.com> you wrote:
> Hi,
> 
> Currently uImages have the load address hardcoded. As we now try to support
> as many ARM platforms as possible with a single binary, this becomes a
> problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> starts at 0x80000000. It's possible to build a kernel image which can deal
> with this, but the uImage still uses a hardcoded address. This results
> in requiring 2 different uImages even though the zImage is the same.
> 
> Has anyone thought of a solution to this problem?

Yes, this has been discussed before.  I proposed to allow for an
offset specification instead of an absolute address.  After that, the
discussions faded.  No code has been submitted yet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Never give in.  Never give in.  Never. Never. Never."
- Winston Churchill