Re: [9fans] raspberry pi 4 arm64 test image

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

new kernel that should be able to deal with the two regions:

http://felloff.net/usr/cinap_lenrek/9pi4

sha1sum:

0222a824ec04c672955560ea120fa4d8de848e79

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Thu, 22 Aug 2019 01:58:39 +0200 cinap_lenrek@felloff.net wrote:
> new kernel that should be able to deal with the two regions:
>
> http://felloff.net/usr/cinap_lenrek/9pi4
>
> sha1sum:
>
> 0222a824ec04c672955560ea120fa4d8de848e79

cat '#ec/*maxmem'
0x3e600000 0x40000000 0xfc000000

Ethernet and sdcard worked fine. Haven't tried usb3 yet.
Nice job!

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

made new image and kernels if anyone wants to test.

http://gabe.felloff.net/usr/cinap_lenrek/9front-7341.7789bbc91c22.pi3.img.gz
http://gabe.felloff.net/usr/cinap_lenrek/9pi3
http://gabe.felloff.net/usr/cinap_lenrek/9pi4

sha1sums:

1b493439cbdff6aa6e0403cc0bda158841ebac40	9front-7341.7789bbc91c22.pi3.img.gz
b5e199a9ee2890929e096b29b6310bc12bbe00a8	9pi3
abc4a73cdffb5d1e0ddc4d86a20b5f2f0509ced0	9pi4

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

> The device tree has two entries.
>
> offset:0
> lenght:0x3c400000
>
> offset:0x40000000
> length:0xbc000000

excellent! that explains it.

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

> The firmware on a pi4 with 2GB or 4GB RAM will only report 1GB.
> I believe you need to look at the board id (or probe for invalid
> addresses as in the teg2 kernel) to find out the real amount.

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...

on what method does it report only 1GB?

i know of 3 methods so far:

- 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.

i'm currently using device tree method, but the code assumes that
there is a single block entry. lets see if that lies as well with
the debug kernel.

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 23:59:28 +0200 cinap_lenrek@felloff.net wrote:
cinap_lenrek@felloff.net writes:
> > The firmware on a pi4 with 2GB or 4GB RAM will only report 1GB.
> > I believe you need to look at the board id (or probe for invalid
> > addresses as in the teg2 kernel) to find out the real amount.
>
> 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...
>
> on what method does it report only 1GB?
>
> i know of 3 methods so far:
>
> - 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.
>
> i'm currently using device tree method, but the code assumes that
> there is a single block entry. lets see if that lies as well with
> the debug kernel.

The device tree has two entries.

offset:0
lenght:0x3c400000

offset:0x40000000
length:0xbc000000

Re: [9fans] raspberry pi 4 arm64 test image

[Richard Miller]

> 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).

Re: [9fans] raspberry pi 4 arm64 test image

[Steve Simon]

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).
> 

Re: [9fans] raspberry pi 4 arm64 test image

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

Couldn't you even manage to try a few wines?

On Thu, Aug 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:
> >    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).
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 1661 bytes --]

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

ok, i prepared a kernel with debug prints. (i basically
buffer the debug outputs in kmesg and dump them on the
serial console and screen once they get initialized).

http://felloff.net/usr/cinap_lenrek/9pi4

i suspect that the device tree /memory/reg property
might not be a single 12 byte entry. and thats why
theres no *maxmem variable in #ec.

i also added some prints to fbinit() just to make
sure...

on my pi4, i get:

/memory/reg[12]: 00000000000000003E600000
confinit: *maxmem=0x3e600000
confinit: memsize=0x3e600000
confinit: getramsize() => 00000000 00000000
confinit: mem[0] => 00000000 3e600000
127 holes free
0x00670000 0x19310000 415891456
415891456 bytes free
fbinit: 1280x1024x16
fbinit: base=fed7b000
fbinit: va=ffffffff1ed7b000

Plan 9
...

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

thank you!

i believe its just starting rio so you dont get any more output.

interestingly, the framebuffer was set up without error as
far as the kernel is concerned. otherwise we would get an
error when trying to attach devdraw.

on the bootargs prompt, enter:

!rc

then on the rc shell:

cat '#ec/*maxmem'

that should be the end of ram that the loader passes to us
in the device tree.

i'll prepare a kernel that you can copy into the sdcard
image with more debug output...

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[Richard Miller]

> cat '#ec/*maxmem'

% cat '#ec/*maxmem'
cat: can't open #ec/*maxmem: '#ec/*maxmem' file does not exist
% ls '#ec'
'#ec/8250.nr_uarts'
'#ec/bcm2708_fb.fbdepth'
'#ec/bcm2708_fb.fbheight'
'#ec/bcm2708_fb.fbswap'
'#ec/bcm2708_fb.fbwidth'
'#ec/cma'
'#ec/coherent_pool'
'#ec/console'
'#ec/smsc95xx.macaddr'
'#ec/vc_mem.mem_base'
'#ec/vc_mem.mem_size'

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 21:53:42 +0200 cinap_lenrek@felloff.net wrote:
cinap_lenrek@felloff.net writes:
> thank you!
>
> i believe its just starting rio so you dont get any more output.
>
> interestingly, the framebuffer was set up without error as
> far as the kernel is concerned. otherwise we would get an
> error when trying to attach devdraw.

The display shows an error "not support" on the screen.
bc2708_fb.fbheight is 1280 and fbwidth 1920 which don't seem
to work on my display. Removing gpu_mem=16 didn't help.  I
didn't get any output - not even the first line.

[9fans] raspberry pi 4 arm64 test image

[cinap_lenrek]

i'v made a sdcard image for the new raspberry pi 4
(also works on 3).

http://gabe.felloff.net/usr/cinap_lenrek/9front-7336.bb28fe19fe44.pi3.img.gz

this has support for most of the new hardware:

sdcard, ethernet and usb3.0

can someone please test this on the 2GB and 4GB
ram variants for me?

--
cinap

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 19:56:08 +0200 cinap_lenrek@felloff.net wrote:
> i'v made a sdcard image for the new raspberry pi 4
> (also works on 3).
>
> http://gabe.felloff.net/usr/cinap_lenrek/9front-7336.bb28fe19fe44.pi3.img.gz
>
> this has support for most of the new hardware:
>
> sdcard, ethernet and usb3.0
>
> can someone please test this on the 2GB and 4GB
> ram variants for me?

Trying this on pi4B4GB

- no display
- on the serial port I see

Plan 9
127 holes free
0x00630060 0x0cf40000 210829216
210829216 bytes free
cpu0: 1500MHz ARM Cortex-A72 r0p3
512M memory: 207M kernel data, 304M user, 1828M swap
bus dev type vid  did intl memory
0   0/0 06 04 00 14e4 2711   0  ->1
1   0/0 0c 03 30 1106 3483   0  0:600000000 4096
#l0: genet: 1000Mbps port 0xBD580000 irq 189 ea dca6320d63de
usbxhci: cpu2: 1500MHz ARM Cortex-A72 r0p3
cpu3: 1500MHz ARM Cortex-A72 r0p3
cpu1: 1500MHz ARM Cortex-A72 r0p3
0x1106 0x3483: port 0x600000000 size 0x1000 irq 0
#l0: phy1 id 600d84a2 oui 80361
nusb/kb: /dev/usb/ep4.0: setproto: Context State Error
nusb/kb: /dev/usb/ep4.0: setproto: no report descriptor

/dev/sdM0: eMMC SD Host Controller 02 Version 10
/dev/sdM0/data
/dev/sdM0/dos    dos
/dev/sdM0/fs     hjfs
/dev/sdM0/nvram
/dev/sdM0/plan9
bootargs is (tcp, tls, il, local!device)[local!/dev/sdM0/fs]
user[glenda]:
hjfs: fs is /dev/sdM0/fs

init: starting /bin/rc
aux/timesync: accessing /dev/rtc: '/dev/rtc' file does not exist
echo: write error: unknown control message "res 3"

Then no response.

Re: [9fans] raspberry pi 4 arm64 test image

[Richard Miller]

> 512M memory: 207M kernel data, 304M user, 1828M swap

The firmware on a pi4 with 2GB or 4GB RAM will only report 1GB.
I believe you need to look at the board id (or probe for invalid
addresses as in the teg2 kernel) to find out the real amount.

Re: [9fans] raspberry pi 4 arm64 test image

[Richard Miller]

> bakul@bitblocks.com>:
>  Trying this on pi4B4GB
>
> - no display

The display does come up for me (using HDMI0 socket).

Re: [9fans] raspberry pi 4 arm64 test image

[Bakul Shah]

On Wed, 21 Aug 2019 21:05:20 +0100 Richard Miller <9fans@hamnavoe.com> wrote:
> > bakul@bitblocks.com>:
> >  Trying this on pi4B4GB
> >
> > - no display
>
> The display does come up for me (using HDMI0 socket).

It is an early 4k Seiki TV/Monitor. It works fine on a pi3
(running your kernel) in 1440x900 res. On pi4 with 9front, it
says "Not support" on the screen so likely some invalid
parameter.

Re: [9fans] raspberry pi 4 arm64 test image

[Richard Miller]

Back in the arm32 world, the contrib/miller/9/bcm kernel source
is now stable and useable on pi4, after fixing some old emmc bugs,
and thanks to cinap for spotting that no-execute bits have to be
set in device space page tables to prevent speculative instruction
fetches from device registers (!).

Wifi is still the only supported device so far.  Rather than
re-inventing wheels, I'll adopt 9front drivers for the rest
(after I've caught up with some other work).