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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
