From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Williams Date: Mon, 10 Oct 2011 19:46:10 -0700 Subject: [U-Boot] [PATCH v3 19/21] Use uintptr_t for 32/64-bit compatibility In-Reply-To: <201110092254.51554.vapier@gentoo.org> References: <1317082255-24247-1-git-send-email-sjg@chromium.org> <201110092254.51554.vapier@gentoo.org> Message-ID: <201110101946.10971.Aaron.Williams@cavium.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 (408) 943-7198