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

[Aaron Williams <Aaron.Williams@cavium.com>]

On Monday, October 10, 2011 09:52:59 PM Mike Frysinger wrote:
> On Monday 10 October 2011 22:46:10 Aaron Williams wrote:
> > 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).
> 
> right, n32 == 32bit pointers, so i don't consider that a port with 64bit
> pointer issues
> 
> > 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).
> 
> what exactly are "proper mapping functions" ?  you mean things like the
> kernel's ioremap() ?
> 
> also, please don't top post
> -mike

I mean using functions like pci_virt_to_mem(). I have fixed a couple of 
drivers such as the USB EHCI driver and Intel E1000 driver to make use of this 
on our platform. We also can optionally perform I/O remapping so that PCI 
devices that only support 32-bit addressing can still access the memory where 
U-Boot is located. I have found that numerous drivers assume that an address 
in a pointer can be used directly for DMA which is not the case on MIPS since 
U-Boot typically runs in KSEG0 (0x8000000) which is aliased to physical memory 
address 0.

The other area I have seen issues is where drivers do not use 
readl/writel/etc. to access the registers. It is even easier if they use a 
macro per-driver since in our case we might use different functions to access 
the underlying hardware registers depending on if they're part of our SOC or 
on the PCIe bus since they map to different 64-bit I/O areas.

Now none of these actually require 64-bit pointers, just 64-bit physical 
addresses. We even support 64-bit ELF executables loaded from U-Boot as well 
as the 64-bit Linux kernel (we don't support a 32-bit kernel any longer) and 
basically make use of a 64-bit version of memcpy.

64-bit support would be useful for the various memory functions, i.e. md, mw, 
mm, md5sum, etc. It can also be useful for loading images to higher addresses. 
It's not essential though and currently we added separate commands for 
accessing 64-bit addresses.

One of these daya I need to work on getting some of our patches back upstream 
since some of them are quite useful for other platforms as well.

Even though we use virtual memory for U-Boot the number of changes to U-Boot 
has been very minimal except for drivers and even then the changes can be 
portable (i.e. using pci_virt_to_mem(). It actually simplifies things in that 
we don't have to deal with remapping. Some drivers like the proposed one for 
the Silicon Image SATA controller work as-is. The virtual memory allows the 
same U-Boot image to run from anywhere in memory. We use a single image 
whether we're booting out of NOR flash or over PCI. We also support multiple 
flash images (standard and failsafe). We perform the mapping before any C code 
is executed so we don't have to worry about relocation when U-Boot copies 
itself to the top of RAM and begins executing there. We do have a very 
different lib/board.c however, in order to deal with our SOC.

I think moving U-Boot to be fully 64-bit will be a lot more difficult compared 
to what we are doing since a lot of code assumes addresses are 32-bit. Our VM 
change allows U-Boot to remain 32-bit while still being able to support a 64-
bit platform.

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