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 mkimage. Bye, Maarten
