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

[Simon Glass]

Hi Mike,

On Sun, Oct 9, 2011 at 7:54 PM, Mike Frysinger <vapier at gentoo.org> 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.

Yes - I don't seem a lot of use in having massive amounts of RAM for
testing U-Boot, so 32-bit addresses should be fine for now.

>
> 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
>

Yes %p is not quite what we want, but as you say this is an error condition.

Regards,
Simon