From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steve Simon <steve@quintile.net>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Thu, 22 Aug 2019 10:58:53 +0200
Message-Id: <F4005D38-D9FE-4DC4-9E20-3F5786A49677@quintile.net>
References: <8cad36b2833c37206e385b368fc2e793@hamnavoe.com>
In-Reply-To: <8cad36b2833c37206e385b368fc2e793@hamnavoe.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] raspberry pi 4 arm64 test image
Topicbox-Message-UUID: 06419a90-eada-11e9-9d60-3106f5b1d025

hi all

just to say i am very excited abou the pi4 port but am on holiday in France a=
t the moment so i cannot even help with testing.

-Steve


On 22 Aug 2019, at 9:07 am, Richard Miller <9fans@hamnavoe.com> wrote:

>> oh dear. i dont even know the expected physical memory map...
>> i guess that ram is continuous block at [0-0xfc000000). but
>> some memory might be reserved...
>=20
> No, the framebuffer is always reserved at the top of the
> first 1GB, so on 2GB and 4GB units there are two separate
> regions.
>=20
>> - atags
>> - device tree /memory/reg property
>> - firmware property request (getramsize() in vcore.c)
>>=20
>> for me getramsize() returns zero for both base and limit so its
>> completely useless.
>=20
> That's strange, getramsize works on my 2GB pi4:
>    getramsize 0 1046478848
>=20
> The same values are in atags (you need 'device_tree=3D' in config.txt
> to make the firmware pass atags instead of devicetree).
>=20