From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <8cad36b2833c37206e385b368fc2e793@hamnavoe.com> In-Reply-To: From: Charles Forsyth Date: Thu, 22 Aug 2019 21:26:27 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000b916d90590ba81fd" Subject: Re: [9fans] raspberry pi 4 arm64 test image Topicbox-Message-UUID: 06478fcc-eada-11e9-9d60-3106f5b1d025 --000000000000b916d90590ba81fd Content-Type: text/plain; charset="UTF-8" Couldn't you even manage to try a few wines? On Thu, Aug 22, 2019 at 9:59 AM Steve Simon wrote: > hi all > > just to say i am very excited abou the pi4 port but am on holiday in > France at 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... > > > > No, the framebuffer is always reserved at the top of the > > first 1GB, so on 2GB and 4GB units there are two separate > > regions. > > > >> - atags > >> - device tree /memory/reg property > >> - firmware property request (getramsize() in vcore.c) > >> > >> for me getramsize() returns zero for both base and limit so its > >> completely useless. > > > > That's strange, getramsize works on my 2GB pi4: > > getramsize 0 1046478848 > > > > The same values are in atags (you need 'device_tree=' in config.txt > > to make the firmware pass atags instead of devicetree). > > > > > --000000000000b916d90590ba81fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Couldn't you even manage to try a few wines?

=
On Thu, Au= g 22, 2019 at 9:59 AM Steve Simon <steve@quintile.net> wrote:
hi all

just to say i am very excited abou the pi4 port but am on holiday in France= at 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...
>
> No, the framebuffer is always reserved at the top of the
> first 1GB, so on 2GB and 4GB units there are two separate
> regions.
>
>> - atags
>> - device tree /memory/reg property
>> - firmware property request (getramsize() in vcore.c)
>>
>> for me getramsize() returns zero for both base and limit so its >> completely useless.
>
> That's strange, getramsize works on my 2GB pi4:
>=C2=A0 =C2=A0 getramsize 0 1046478848
>
> The same values are in atags (you need 'device_tree=3D' in con= fig.txt
> to make the firmware pass atags instead of devicetree).
>


--000000000000b916d90590ba81fd--