[U-Boot] [PATCH v3 19/21] Use uintptr_t for 32/64-bit compatibility

[Aaron Williams]

Our OCTEON platform is a 64-bit SOC and we run it in the MIPS N32 ABI mode 
(64-bit registers, 32-bit address space). In our case we use virtual memory so 
we can move U-Boot to the top of memory which is often above 4GB. The only 
changes we had to make to U-Boot was that drivers need to use the proper 
mapping functions and support 64-bit physical addresses. Generally the 
hardware devices support this and the driver changes have been minimal. Some 
of our boards have over 8GB of RAM installed and 4GB is common for us. With 
the hole we create for our boot bus (flash, etc.) that means that in many 
cases U-Boot is loaded above the 32-bit boundary. By using a couple of TLB 
entries on MIPS we always map U-Boot to 0xC0000000 no matter where it is 
executing from. While a 64-bit U-Boot would be nice, we don't really need it 
since the TLB solves all of our issues. I would rather see drivers better make 
use of the proper mapping functions and support 64-bit physical addresses as 
well as use wrappers for accessing the PCI register space. (in our case all of 
our SOC registers require 64-bit addresses).

-Aaron

On Sunday, October 09, 2011 07:54:50 PM Mike Frysinger wrote:
> On Tuesday 04 October 2011 01:24:56 Simon Glass wrote:
> > On Mon, Oct 3, 2011 at 11:57 AM, Mike Frysinger wrote:
> > > On Monday, September 26, 2011 20:10:53 Simon Glass wrote:
> > >> --- a/common/cmd_mem.c
> > >> +++ b/common/cmd_mem.c
> > >> 
> > >>                               printf ("\nMem error @ 0x%08X: "
> > >>                               
> > >>                                       "found %08lX, expected %08lX\n",
> > >> 
> > >> -                                     (uint)addr, readback, val);
> > >> +                                     (uint)(uintptr_t)addr, readback,
> > >> val);
> > > 
> > > could you change the printf format to %#p instead (and drop the casts
> > > completely for "addr") ?
> > 
> > Well it's not complete clear where we want to go with this. My current
> > thinking is that the emulated memory will be small (in 2011 terms) -
> > maybe 128MB. The real memory of the machine is not accessible since it
> > doesn't make sense. So perhaps just because the host happens to be a
> > 64-bit machine we don't suddenly want to be printing 64-bit addresses.
> > 
> > So the answer is 'yes' but for now I'm not sure that's the right thing
> > to do. I have another patch which enables 'md', etc. but of course
> > only within the 128MB 'emulated' memory area.
> > 
> > It actually brings up a question - does U-Boot run on 64-machines?
> 
> i don't believe u-boot runs on any 64bit system (or at least, in 64bit
> mode). there's quite a lot of random assumptions all over the tree where
> pointers are stored in 32bits, so for making sandbox work on 64bit stuff,
> i would focus on making stuff work with minimal intrusion for 32bit
> systems.
> 
> although thinking about this a bit more, %p will not zero pad its output (i
> think even if you specify like "08" it'll get ignored).  but maybe people
> don't care as normally this output shouldn't occur ?
> -mike

-- 
Aaron Williams <Aaron.Williams at cavium.com>
 (408) 943-7198