Re: Hmmmm.... wha happen?

On 8/19/2021 07:29, Karl Denninger wrote:
>
> On 8/18/2021 22:08, Herbert J. Skuhra wrote:
>> On Wed, Aug 18, 2021 at 08:41:08PM -0400, Karl Denninger wrote:
>>> Ok, did I screw this up or did the updates to the RPI firmware 
>>> somewhere
>>> blow things up for a 3 Model B?  The SD card slot appears to have
>>> disappeared.
>> https://lists.freebsd.org/archives/freebsd-arm/2021-July/000343.html
>>
>> https://lists.freebsd.org/archives/freebsd-arm/2021-July/000371.html
>
> So..... if I'm running packages......
>
> (I suppose I could try to "overload" the rpi-3 uboot port, which, it 
> appears, is 2017.01!  Uh, that's probably not what I want EITHER.)
>
Well now I may have a dead end for the moment.

Just blew away the ports tree on the box, fetched the current one, and 
attempted to build just sysutils/u-boot-rpi3 and got:

......

In file included from tools/kwbimage.c:14:
In file included from include/image.h:19:
In file included from ./arch/sandbox/include/asm/byteorder.h:20:
In file included from include/linux/byteorder/little_endian.h:13:
/usr/local/include/linux/types.h:9:18: error: typedef redefinition with
       different types ('uint64_t' (aka 'unsigned long') vs 'unsigned 
long long')
typedef uint64_t __u64;
                  ^
include/asm-generic/int-ll64.h:29:42: note: previous definition is here
__extension__ typedef unsigned long long __u64;

and that's that, so obviously there's something in the port requirement 
that is not on the box and the ports system, when trying to build this 
port alone, fails to resolve.

It's blowing up in u-boot-tools which has to build first.

Can't patch the code if it won't build.  I'll see if I can find an older 
copy of u-boot for the RPI3 somewhere.

Crap.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/