On Wednesday 24 October 2012 19:43:25 Florian Fainelli wrote:
> On Wednesday 24 October 2012 18:16:35 Maarten ter Huurne wrote:
> > On Tuesday 23 October 2012 21:43:59 Antony Pavlov wrote:
> > > Add the Kbuild files for the JZ4750D architecture and adds JZ4750D
> > > support to the MIPS Kbuild files.
> > [snip]
> > > diff --git a/arch/mips/jz4750d/Platform b/arch/mips/jz4750d/Platform
> > > new file mode 100644
> > > index 0000000..2e4e050
> > > --- /dev/null
> > > +++ b/arch/mips/jz4750d/Platform
> > > @@ -0,0 +1,3 @@
> > > +platform-$(CONFIG_MACH_JZ4750D) += jz4750d/
> > > +cflags-$(CONFIG_MACH_JZ4750D) +=
> > > -I$(srctree)/arch/mips/include/asm/mach-jz4750d
> > > +load-$(CONFIG_MACH_JZ4750D) += 0xffffffff80010000
> > What is the purpose of padding the load address to 64 bits?
> > The reason I'm asking is that we encountered a bug with that when
> > creating a u-boot image on a 32-bit host machine: the mkimage tool will
> > only parse the first 8 hex digits and then inserts the wrong load
> > address into the uImage.
> AFAIR u-boot's mkimage expects 32-bits quantities as a load address, so I
> would not be surprised that using this line as-is as an input parameter
> to mkimage does not give yout the expected result.
The actual uImage format supports only 32-bit addresses, but mkimage is
inconsistent in its handling of 64-bit addresses: if the tool is compiled
for x86_64 it parses all 16 hex digits and uses the lower 32 bits, but if it
is compiled for x86 it parses only the first 8 hex digits and the resulting
image won't boot.
There is no "uImage" target for MIPS in the mainline kernel; we added our
own and it indeed passes $(VMLINUX_LOAD_ADDRESS) to mkimage as-is on the
command line. Since Ralf indicated that there are good reasons for sign
extending the address, I think I'll have to change how it is passed to