* Re: [9front] rpi4B (4GB) model
@ 2020-04-20 6:47 kokamoto
0 siblings, 0 replies; 14+ messages in thread
From: kokamoto @ 2020-04-20 6:47 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-30 9:41 ` kokamoto
@ 2020-04-30 10:21 ` hiro
0 siblings, 0 replies; 14+ messages in thread
From: hiro @ 2020-04-30 10:21 UTC (permalink / raw)
To: 9front
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
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-30 7:54 ` hiro
@ 2020-04-30 9:41 ` kokamoto
2020-04-30 10:21 ` hiro
0 siblings, 1 reply; 14+ messages in thread
From: kokamoto @ 2020-04-30 9:41 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-30 6:20 ` kokamoto
2020-04-30 6:21 ` kokamoto
@ 2020-04-30 7:54 ` hiro
2020-04-30 9:41 ` kokamoto
1 sibling, 1 reply; 14+ messages in thread
From: hiro @ 2020-04-30 7:54 UTC (permalink / raw)
To: 9front
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-30 6:20 ` kokamoto
@ 2020-04-30 6:21 ` kokamoto
2020-04-30 7:54 ` hiro
1 sibling, 0 replies; 14+ messages in thread
From: kokamoto @ 2020-04-30 6:21 UTC (permalink / raw)
To: 9front
Ican run linux (Ubuntu make) safely on this machine
before the new case with fan.
Kenji
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-22 17:52 ` cinap_lenrek
@ 2020-04-30 6:20 ` kokamoto
2020-04-30 6:21 ` kokamoto
2020-04-30 7:54 ` hiro
0 siblings, 2 replies; 14+ messages in thread
From: kokamoto @ 2020-04-30 6:20 UTC (permalink / raw)
To: 9front
>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-21 22:31 kokamoto
@ 2020-04-22 17:52 ` cinap_lenrek
2020-04-30 6:20 ` kokamoto
0 siblings, 1 reply; 14+ messages in thread
From: cinap_lenrek @ 2020-04-22 17:52 UTC (permalink / raw)
To: 9front
> Yes, its patch solved the problem.
> Now, I have 4008M memory!
excellent! i will commit it.
--
cinap
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
@ 2020-04-21 22:31 kokamoto
2020-04-22 17:52 ` cinap_lenrek
0 siblings, 1 reply; 14+ messages in thread
From: kokamoto @ 2020-04-21 22:31 UTC (permalink / raw)
To: 9front
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;
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-20 1:31 kokamoto
@ 2020-04-21 9:06 ` cinap_lenrek
0 siblings, 0 replies; 14+ messages in thread
From: cinap_lenrek @ 2020-04-21 9:06 UTC (permalink / raw)
To: 9front
> 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;
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
@ 2020-04-20 1:31 kokamoto
2020-04-21 9:06 ` cinap_lenrek
0 siblings, 1 reply; 14+ messages in thread
From: kokamoto @ 2020-04-20 1:31 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-14 5:20 kokamoto
@ 2020-04-18 17:01 ` cinap_lenrek
0 siblings, 0 replies; 14+ messages in thread
From: cinap_lenrek @ 2020-04-18 17:01 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
2020-04-16 5:30 kokamoto
@ 2020-04-18 16:52 ` cinap_lenrek
0 siblings, 0 replies; 14+ messages in thread
From: cinap_lenrek @ 2020-04-18 16:52 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
@ 2020-04-16 5:30 kokamoto
2020-04-18 16:52 ` cinap_lenrek
0 siblings, 1 reply; 14+ messages in thread
From: kokamoto @ 2020-04-16 5:30 UTC (permalink / raw)
To: 9front
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [9front] rpi4B (4GB) model
@ 2020-04-14 8:19 kokamoto
0 siblings, 0 replies; 14+ messages in thread
From: kokamoto @ 2020-04-14 8:19 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-30 10:21 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-20 6:47 [9front] rpi4B (4GB) model kokamoto
-- strict thread matches above, loose matches on Subject: below --
2020-04-21 22:31 kokamoto
2020-04-22 17:52 ` cinap_lenrek
2020-04-30 6:20 ` kokamoto
2020-04-30 6:21 ` kokamoto
2020-04-30 7:54 ` hiro
2020-04-30 9:41 ` kokamoto
2020-04-30 10:21 ` hiro
2020-04-20 1:31 kokamoto
2020-04-21 9:06 ` cinap_lenrek
2020-04-16 5:30 kokamoto
2020-04-18 16:52 ` cinap_lenrek
2020-04-14 8:19 kokamoto
2020-04-14 5:20 kokamoto
2020-04-18 17:01 ` [9front] " cinap_lenrek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).