svn commit: r293053 - head/sys/boot/uboot/lib

[Justin Hibbits]

On Sat, Jan 2, 2016 at 4:46 PM, Ian Lepore <ian at freebsd.org> wrote:
> On Sat, 2016-01-02 at 22:20 +0000, Bjoern A. Zeeb wrote:
>> > On 02 Jan 2016, at 18:16 , Ian Lepore <ian at freebsd.org> wrote:
>> >
>> > Author: ian
>> > Date: Sat Jan  2 18:16:24 2016
>> > New Revision: 293053
>> > URL: https://svnweb.freebsd.org/changeset/base/293053
>> >
>> > Log:
>> >  Use 64-bit math when finding a block of ram to hold the kernel.
>> >  This fixes
>> >  a problem on 32-bit systems which have ram occupying the end of
>> > the physical
>> >  address space -- for example, a block of ram at 0x80000000 with a
>> > size of
>> >  0x80000000 was overflowing 32 bit math and ending up with a
>> > calculated size
>> >  of zero.
>> >
>> >  This is a fix for one of the two problems mentioned in the PR.
>> >  Something
>> >  similar will need to be done on the kernel side before the PR is
>> > closed.
>> >
>> >  PR:                201614
>> >
>> > Modified:
>> >  head/sys/boot/uboot/lib/copy.c
>>
>>
>> This seems to have broken powerpc/powerpc64 worlds:
>>
>> ===> sys/boot/uboot/lib (all)
>> cc1: warnings being treated as errors
>> /scratch/tmp/bz/head.svn/sys/boot/uboot/lib/copy.c: In function
>> 'uboot_loadaddr':
>> /scratch/tmp/bz/head.svn/sys/boot/uboot/lib/copy.c:103: warning: cast
>> from pointer to integer of different size
>> --- copy.o ---
>> *** [copy.o] Error code 1
>>
>
> Grrrr.  Casting from a pointer to an integer of a different size is
> exactly what I want to do, and I thought explicitly casting was a
> rather elegant way of expressing that.
>
> -- Ian
>
>

Casting through uintptr_t should solve the problem.

- Justin