Re: [9front] rpi4B (4GB) model

Re: [9front] rpi4B (4GB) model

[kokamoto]

Hi, cinap, thank you very much!

Yes, its patch solved the problem.
Now, I have 4008M memory!

Now, I'm writing this mail on the new arm64 rpi4 board.

Kenji


> you can try the following patch?
> 
> diff -r f9f922fd127d sys/src/9/bcm/bootargs.c
> --- a/sys/src/9/bcm/bootargs.c	Mon Apr 20 00:08:35 2020 +0200
> +++ b/sys/src/9/bcm/bootargs.c	Tue Apr 21 10:59:21 2020 +0200
> @@ -89,7 +89,8 @@
>  static void
>  devtreeprop(char *path, char *key, void *val, int len)
>  {
> -	if(strcmp(path, "/memory") == 0 && strcmp(key, "reg") == 0){
> +	if((strcmp(path, "/memory") == 0 || strcmp(path, "/memory@0") == 0)
> +	&& strcmp(key, "reg") == 0){
>  		if(findconf("*maxmem") < 0 && len > 0 && (len % (3*4)) == 0){
>  			uvlong top;
>  			uchar *p = val;

Re: [9front] rpi4B (4GB) model

[cinap_lenrek]

> Yes, its patch solved the problem.
> Now, I have 4008M memory!

excellent! i will commit it.

--
cinap

Re: [9front] rpi4B (4GB) model

[kokamoto]

>> Yes, its patch solved the problem.
>> Now, I have 4008M memory!

I tested a new 4B case with wind fan, and found it's unstable still.
I had experienced this unstableness before, and ordered a new
case, and found yhis unstable again.

When I'm reading mails and tried to save a bit long mail,
the acme Mail stalled. However, I can open another rio
window, which seems to me that a core is still working.
It, however, stall very soon.

I cannot predict when, or what condition makes it stall...

Kenji

Re: [9front] rpi4B (4GB) model

[kokamoto]

Ican run linux (Ubuntu make) safely on this machine
before the new case with fan.

Kenji

Re: [9front] rpi4B (4GB) model

[hiro]

did you try with root from another fs to make sure its not the sd interface?

kokamoto@hera.eonet.ne.jp wrote:

>>> Yes, its patch solved the problem.
>>> Now, I have 4008M memory!
>
>I tested a new 4B case with wind fan, and found it's unstable still.
>I had experienced this unstableness before, and ordered a new
>case, and found yhis unstable again.
>
>When I'm reading mails and tried to save a bit long mail,
>the acme Mail stalled. However, I can open another rio
>window, which seems to me that a core is still working.
>It, however, stall very soon.
>
>I cannot predict when, or what condition makes it stall...
>
>Kenji

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [9front] rpi4B (4GB) model

[kokamoto]

> did you try with root from another fs to make sure its not the sd interface?

Ok, I tried booting from local device (/dev/sdM0/fs) as glenda.

I can do some more things, however, I did experience stall of acme,
after 150MB files (30, 30, 30 MB etc) copy from my 9front server.
Interestingly, stats program is still running, and the number on the l line
increases.

Kenji

Re: [9front] rpi4B (4GB) model

[hiro]

yeah, try to minimize the used number of hardware interfaces first.
first netboot from 9front server, then do a plain fcp or something
perhaps and see if you can create a reproducible minimal testcase?

On 4/30/20, kokamoto@hera.eonet.ne.jp <kokamoto@hera.eonet.ne.jp> wrote:
>> did you try with root from another fs to make sure its not the sd
>> interface?
>
> Ok, I tried booting from local device (/dev/sdM0/fs) as glenda.
>
> I can do some more things, however, I did experience stall of acme,
> after 150MB files (30, 30, 30 MB etc) copy from my 9front server.
> Interestingly, stats program is still running, and the number on the l line
> increases.
>
> Kenji
>
>

Re: [9front] rpi4B (4GB) model

[cinap_lenrek]

> I cannot find '#ec/*memsize', found only
> 8250.nr_uarts, bcm2708_fb.fbdepth, bcm2708_fb.fbheight, bcm2708_fb_fbswap, bcm2708_fb_fbwidth
> cma, coherent_pool, console, smsc95xx.macaddr, vc_mem.mem_base, vc_mem.mem_size.

ok,

this means we couldnt detect the memory size from device tree.

looks like they changed the device tree names arround:

https://github.com/raspberrypi/linux/commit/4b17654f51fd87c42cda3217b0863e6aa1df49b9#diff-ac03c9402b807c11d42edc9e8d03dfc7

you can try the following patch?

diff -r f9f922fd127d sys/src/9/bcm/bootargs.c
--- a/sys/src/9/bcm/bootargs.c	Mon Apr 20 00:08:35 2020 +0200
+++ b/sys/src/9/bcm/bootargs.c	Tue Apr 21 10:59:21 2020 +0200
@@ -89,7 +89,8 @@
 static void
 devtreeprop(char *path, char *key, void *val, int len)
 {
-	if(strcmp(path, "/memory") == 0 && strcmp(key, "reg") == 0){
+	if((strcmp(path, "/memory") == 0 || strcmp(path, "/memory@0") == 0)
+	&& strcmp(key, "reg") == 0){
 		if(findconf("*maxmem") < 0 && len > 0 && (len % (3*4)) == 0){
 			uvlong top;
 			uchar *p = val;

Re: [9front] rpi4B (4GB) model

[kokamoto]

Ok, this a comparison between the two cases:
1) older version of bcm firmware
--rw-rw-rw- M 26 sys      sys   1494 Sep 23  2019 LICENCE.broadcom
--rw-rw-rw- M 26 sys      sys  40559 Sep 23  2019 bcm2711-rpi-4-b.dtb
--rw-rw-rw- M 26 sys      sys  52296 Sep 23  2019 bootcode.bin
--rw-rw-rw- M 26 sys      sys   3073 Sep 23  2019 fixup4cd.dat
--rw-rw-rw- M 26 sys      sys   2657 Sep 23  2019 fixup_cd.dat
--rw-rw-rw- M 26 sys      sys 770592 Sep 23  2019 start4cd.elf
--rw-rw-rw- M 26 sys      sys 685636 Sep 23  2019 start_cd.elf

bootup as 4006M memory: 998M kernel data, 3008M user, 15011M swap
This is very unstable, stalls very often (randamly, particularly a large data
exchange between the terminal and 9front file server).

2) new firmware
--rw-rw-r-- M 26 kokamoto sys   1594 Nov 19 08:55 LICENCE.broadcom
--rw-rw-r-- M 26 kokamoto sys  40835 Apr 16 10:12 bcm2711-rpi-4-b.dtb
--rw-rw-r-- M 26 kokamoto sys  52360 Apr 16 10:12 bootcode.bin
--rw-rw-r-- M 26 kokamoto sys   3147 Apr 16 10:12 fixup4cd.dat
--rw-rw-r-- M 26 kokamoto sys   2663 Apr 16 10:12 fixup_cd.dat
--rw-rw-r-- M 26 kokamoto sys 798268 Apr 16 10:12 start4cd.elf
--rw-rw-r-- M 26 kokamoto sys 694052 Apr 16 10:12 start_cd.elf

bootup as 512M memory: 208M kernel data, 304M user, 1825M swap

Kenji

Re: [9front] rpi4B (4GB) model

[kokamoto]

I reconstructed new pi3.img with new firmwares under /sys/lib/dist,
and booted it up.

I cannot find '#ec/*memsize', found only
8250.nr_uarts, bcm2708_fb.fbdepth, bcm2708_fb.fbheight, bcm2708_fb_fbswap, bcm2708_fb_fbwidth
cma, coherent_pool, console, smsc95xx.macaddr, vc_mem.mem_base, vc_mem.mem_size.

cat '#ec/vc_mem.mem_size' reports 0x3f600000, and
cat '#ec/vc_mem.mem_base 0x3f000000

I tried to use new firmware, because I experienced unstable
behaviour when try to send/receive a larger data (sending mail is one of this)
through network.
I thought it might be caused by a older version of firmware I used...

Kenji

Re: [9front] rpi4B (4GB) model

[cinap_lenrek]

> I tried to write this mail on this board, and send it.
> It failed to send it by unknown reason, where system stalls.

sorry kenji, but this is too unspecific for me todo anything
about.

--
cinap

Re: [9front] rpi4B (4GB) model

[cinap_lenrek]

> What I did bad?

It is possible that the firmware changed the format of the
device tree?

The kernel uses device tree to determine the memory size and
adds a *memsize=<topaddr1> <base2> <topaddr2> ... parameter
to  the boot configuration.

you can try to read it with if it is there:

cat '#ec/*memsize'

if that file is missing, it could be that the device tree is
not passed to the kernel or the field format has changed somehow
with the new firmware.

the relevant code is in bcm/bootargc.c where devtreeprop() gets
called for every device tree property and we filter out the
/memory/reg property and add a *maxmem boot parameter when
it does not already exist.

debugging is a bit tricky in that code because we havnt setup
the framebuffer or serial console yet.

i only got a raspi4 with 2gb. but i can still try to see if it
can be reproduced here with the latest firmware. if i can find
the time...

--
cinap

Re: [9front] rpi4B (4GB) model

[kokamoto]

I updated firmware files under/sys/src/boot/bcm.
bootcode.bin 52304 ==> 52360
fixup_cd.dat   3089  ==> 2663
start_cd.elf  688068 ==> 694052
start4cd.elf  775808 ==> 798268
bcm2711-rpi-4-b.dtb  40659  ==> 40835 bytes
(all the files are newest from raspberrypi site.

Then, I got strange boot like:

127 holes free
0x004e0000 0x0cfc0000 212729856
212729856 bytes free

Plan9
cpu0: 1500MHz ARM Cortex-A72 rop3
512M memory: 208M kernel data, 304M user, 1825M swap
...

cat /env/cputype shows arm64

What I did bad?

Kenji

PS: This mail is delivered from rpi4B (4GB) of original one

Re: [9front] rpi4B (4GB) model

[kokamoto]

> I tried to write this mail on this board, and send it.
> It failed to send it by unknown reason, where system stalls.

I meant system hang at smtp send mail, which
may indicate ether dev problem...

Kenji

PS: sorry sent simillar two messages