9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] PXE booting Rpi
@ 2021-03-10 14:05 Daniel Morandini
  2021-03-10 17:20 ` cinap_lenrek
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-03-10 14:05 UTC (permalink / raw)
  To: 9front

Hi folks,
I’m not able to understand what is missing, but my Rpi2 model B is
not PXE booting. The device has the bootcode.bin file in its fat
partition, it successfully makes the DHCP discovery:
```
030500 ms 
	ether(s=b827ebeda1c9 d=ffffffffffff pr=0800 ln=364)
	ip(s=0.0.0.0 d=255.255.255.255 id=0000 frag=0000 ttl=128 pr=17 ln=350)
	udp(s=68 d=67 ck=0000 ln= 330)
	bootp(t=Req ht=1 hl=6 hp=0 xid=26f30339 sec=0 fl=0000 ca=0.0.0.0 ya=0.0.0.0 sa=0.0.0.0 ga=0.0.0.0 cha=b827ebeda1c9 magic=63825363)
	dhcp(t=Discover  requested=(43 60 67 128 129 130 131 132 133 134 135 66 1 3) T93=0000 T94=010201 T97=00c9a1ed94c9a1ed94c9a1ed94c9a1ed94 vendorclass=PXEClient:Arch:00000:UNDI:002001)
030504 ms 
	ether(s=dca63262c202 d=b827ebeda1c9 pr=0800 ln=312)
	ip(s=10.1.1.1 d=10.1.1.2 id=43e3 frag=0000 ttl=255 pr=17 ln=298)
	udp(s=67 d=68 ck=d9f6 ln= 278)
	bootp(t=Rep ht=1 hl=6 hp=0 xid=26f30339 sec=0 fl=0000 ca=0.0.0.0 ya=10.1.1.2 sa=10.1.1.1 ga=0.0.0.0 cha=b827ebeda1c9 magic=63825363 snam=filefucker file=/arm/9pi2)
	dhcp(t=Offer lease=1800 serverid=(10.1.1.1) mask=(255.255.255.0) router=(10.1.1.254) vendorinfo=)

```
My DHCP server makes an offer but its never accepted (I never see
a subsequent TFTP RRQ packet, the Discover request keeps on popping).

I’m looking at [1] and it says:
```
The important part of the reply is the Vendor-Option Option 43.
This needs to contain the string "Raspberry Pi Boot", although, due
to a bug in the boot ROM, you may need to add three spaces to the
end of the string.
```
Which I'm not sending apparently. The documentation we have though
does not say anything about this detail; I assume I’m not the only
one that wants to PXE boot some pi’s with 9front, hence I infer the
problem is somewhere else. This is my network setup (stripped)
```
sys=filefucker
	ether=dca63262c202
	ip=10.1.1.1

sys=authtrouble
	ether=b827ebeda1c9
	ip=10.1.1.2
	bootf=/arm/9pi2
	
sys=thinkterm
	ether=843a4bd682ac

sys=fastgate
	ether=88e9fe6af9e9
	ip=10.1.1.254

ipnet=home
	ip=10.1.1.0
	ipmask=255.255.255.0
	fs=filefucker
	auth=authtrouble
	tftp=filefucker
	ipgw=10.1.1.254
	dns=fastgate
```

Ideas? Just wondering, do we have a custom bootcode.bin that I should
be using?

Thanks in advance,
Cheers
dan

[1] https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md
[2] http://man.cat-v.org/plan_9/8/booting

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-10 14:05 [9front] PXE booting Rpi Daniel Morandini
@ 2021-03-10 17:20 ` cinap_lenrek
  2021-03-12 10:36   ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-03-10 17:20 UTC (permalink / raw)
  To: 9front

you need to add this attribute to the host tuple:

	vendor="Raspberry Pi Boot"

(listed in dhcpd(8) and ndb(8) manpages)

for bootf=, i think you need to specify bootcode.bin,
the bootcode then will construct a tftp path that
includes the mac address to fetch cmdline.txt and
the kernel (and all the other files that you would
normally stash on the sd card).

--
cinap

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-10 17:20 ` cinap_lenrek
@ 2021-03-12 10:36   ` Daniel Morandini
  2021-03-25 10:55     ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-03-12 10:36 UTC (permalink / raw)
  To: 9front

Hi cinap,
Thanks for answering and sorry for bothering.

> you need to add this attribute to the host tuple:
> 	vendor="Raspberry Pi Boot"
> (listed in dhcpd(8) and ndb(8) manpages)
I did not notice this was the parameter I was looking for \o/

> for bootf=, i think you need to specify bootcode.bin,
> the bootcode then will construct a tftp path that
> includes the mac address to fetch cmdline.txt and
> the kernel (and all the other files that you would
> normally stash on the sd card).
I did not finish everything, just a quick update for the record. I
created a folder in /lib/pxe/<pi serial number> that holds the files
required for the boot.  The tftpd (and dhcpd) server is pointing
its home directory to /lib/pxe. I did it because bootcode.bin (which
is on the sd card, my rasp won’t pxe boot without it) prepends the
serial number to its file requests. I would have preferred to use
the .[ICE] naming convention found in the code, but that’s out of my
control as long as I keep using the standard bootcode.bin.

The pi boots :D For now the problem is the cmdline.txt file (which
is transferred by tftpd) is not forwarded correctly to the kernel,
so my "plan9.ini" configuration is not applied.  I’m still debugging
this.

Cheers,
dan

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-12 10:36   ` Daniel Morandini
@ 2021-03-25 10:55     ` Daniel Morandini
  2021-03-25 18:49       ` Noam Preil
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-03-25 10:55 UTC (permalink / raw)
  To: 9front

Hi people,
some updates (pi is still not getting my cmdline.txt args):

According to the UART logs, it looks like bootcode.bin is NOT
fetching the cmdline.txt file.

As soon as I do not know how and when this logs are emitted, I
double checked on the kernel side: In bcm, I added a “confdump”
function that dumps confname and confval values up to nconf as soon
as print is available, after the “bootargsinit” call in main.c:
empty.

I checked the Atag parsing code and it looks like we do not pass
the `if(parseatags(va, len) == 0 || parsedevtree(va, len) == 0`
line, hence no atag is parsed.

I compared miller’s bcm code and its logic seemed pretty similar
on this regard, I double checked by booting the rasp using his
kernel and indeed no configuration is parsed in that case too.

What I find wierd is that if I add the cmdline.txt file to
the sd card directly it is NOT read as well.

This is the contents of the file (xd -c cmdline.txt):
```
0000000   u  s  e  r  =  d  a  n \n
0000009
```

Do you have any idea? I’m at the “what the fuck” point :D

Cheers,
dan

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-25 10:55     ` Daniel Morandini
@ 2021-03-25 18:49       ` Noam Preil
  2021-03-25 21:49         ` Noam Preil
  2021-04-07  8:39         ` Daniel Morandini
  0 siblings, 2 replies; 17+ messages in thread
From: Noam Preil @ 2021-03-25 18:49 UTC (permalink / raw)
  To: Daniel Morandini

I boot from SD; all I can day is that your cmdline looks correct.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-25 18:49       ` Noam Preil
@ 2021-03-25 21:49         ` Noam Preil
  2021-04-07  8:39         ` Daniel Morandini
  1 sibling, 0 replies; 17+ messages in thread
From: Noam Preil @ 2021-03-25 21:49 UTC (permalink / raw)
  To: Noam Preil



> I boot from SD; all I can day is that your cmdline looks correct.

... s/day/say/

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-03-25 18:49       ` Noam Preil
  2021-03-25 21:49         ` Noam Preil
@ 2021-04-07  8:39         ` Daniel Morandini
  2021-04-08 14:21           ` cinap_lenrek
  1 sibling, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-04-07  8:39 UTC (permalink / raw)
  To: 9front

Hi people,
9pi2 is now getting its kernel configuration params! :D

Summary: add a “device_tree=“ line to your config.txt file if you
want your bcm pi to load cmdline.txt (9front 18e1e1c3aaf1, bootcode.bin
from [4] 8717598).

I spotted the “problem" in bcm/bootargs.c, `bootargsinit`.
```
void
bootargsinit(uintptr pa)
{
	uintptr len;

	/*
	 * kernel gets DTB/ATAGS pointer in R0 on entry
	 */
	if(pa != 0 && (len = cankaddr(pa)) != 0){
		void *va = KADDR(pa);
		if(parseatags(va, len) == 0 || parsedevtree(va, len) == 0) {
			return;
		}
	}

	/*
	 * /dev/reboot case, check CONFADDR
	 */
	if(parseatags(BOOTARGS, BOOTARGSLEN) != 0)
		plan9iniinit(BOOTARGS, 0);
}
```
Some notes. DTB/ATAGS pointer is passed to R2 on entry, not R0,
according to [1] and [2].
We call bootargsinit(0) though (main.c:87), so the first if statement
is never asserted, at least from the references within the bcm
folder.

Now according to the comment we should reach the second block only
when rebooting (?), but apparently this is not true. Quoting [3],

> The firmware will always try to load the DT and pass it to the
> kernel, since all kernels since rpi-4.4.y will not function without
> a DTB. You can override this by adding device_tree= in config.txt,
> which forces the use of ATAGs, which can be useful for simple
> "bare-metal" kernels.

And that was it! The second block in fact does not try to parse a
device tree but atags.

Why is bootargsinit called with pa=0? I think this function is not
working as intended anymore!

Cheers,
dan

[1] https://wiki.osdev.org/ARM_RaspberryPi
[2] http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#appendix_tag_reference
[3] https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3
[4] https://github.com/raspberrypi/firmware/blob/master/boot/bootcode.bin

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-07  8:39         ` Daniel Morandini
@ 2021-04-08 14:21           ` cinap_lenrek
  2021-04-08 15:45             ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-04-08 14:21 UTC (permalink / raw)
  To: 9front

you have to distinguish the bcm and bcm64 kernels.

in bcm64, a arm64 kernel, device tree is passed in R0.

the devicetree support was implemented for raspberry pi 4 as the
newer firmware didnt provide atags. and we also need devicetree
now as they move the pci windows around in physical memory depending
on the model (cm4, pi400).

in the 32 bit bcm kernel, the ATAGS where always located at a fixed
memory location 0x100. devicetree was not used. it is possible
that this assumption doesnt hold anymore and now atags are at
a variable address passed in R2 as you say?

note, i didnt come up with this logic. and didnt pay too much
attention on the 32 bit bcm kernels and their newer firmware
incarnations.

it might be confusinbg as bcm/bootargs.c is shared between
the bcm and bcm64 kernels.

--
cinap

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-08 14:21           ` cinap_lenrek
@ 2021-04-08 15:45             ` Daniel Morandini
  2021-04-08 16:12               ` cinap_lenrek
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-04-08 15:45 UTC (permalink / raw)
  To: 9front

Hey cinap!

> you have to distinguish the bcm and bcm64 kernels.
> in bcm64, a arm64 kernel, device tree is passed in R0.
I checked bcm only for now!

> in the 32 bit bcm kernel, the ATAGS where always located at a fixed
> memory location 0x100. devicetree was not used. it is possible
> that this assumption doesnt hold anymore and now atags are at
> a variable address passed in R2 as you say?
The 0x100 assumption still holds, but according to the Rpi docs
here [1] (mentioned in the previous mail) rpi fw (I don’t know when
this change occurred) will always give precedence to dtree as as
you say, from pi4 that’s the only supported method.

> note, i didnt come up with this logic. and didnt pay too much
> attention on the 32 bit bcm kernels and their newer firmware
> incarnations.
I see!

> the devicetree support was implemented for raspberry pi 4 as the
> newer firmware didnt provide atags. and we also need devicetree
> now as they move the pci windows around in physical memory depending
> on the model (cm4, pi400).

> it might be confusinbg as bcm/bootargs.c is shared between
> the bcm and bcm64 kernels.
What if we always try dtree first and fallback to atags for the bcm
kernel only? I’ll take care of it if it sounds good to you!

Cheers,
dan

[1] https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-08 15:45             ` Daniel Morandini
@ 2021-04-08 16:12               ` cinap_lenrek
  2021-04-11 12:11                 ` cinap_lenrek
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-04-08 16:12 UTC (permalink / raw)
  To: 9front

> What if we always try dtree first and fallback to atags for the bcm
> kernel only? I’ll take care of it if it sounds good to you!

sure, we can try it. 

the logic would be similar to the bcm64/main.c, passing the
value of R2...

send a patch!

i just need some time to burry up my old pi1 and pi2 to test it...
hopefully it wouldnt break on old firmware :)

--
cinap

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-08 16:12               ` cinap_lenrek
@ 2021-04-11 12:11                 ` cinap_lenrek
  2021-04-12  9:04                   ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-04-11 12:11 UTC (permalink / raw)
  To: 9front

> What if we always try dtree first and fallback to atags for the bcm
> kernel only? I’ll take care of it if it sounds good to you!

ok, i just tried the 32 bit pi2 kernel with a raspberry pi 3B+ 
pxeboot and the R2 register appears to be zero on entry.

this is with the latest bootcode.bin and start_cd*.elf:

term% sha1sum bootcode.bin fixup_cd.dat start_cd.elf
76b71ff97ace39d9900c27f761f7548c4c6f49a5	bootcode.bin
1585386a20cfc42b541f3ed1439d90e8c5b4529e	fixup_cd.dat
e08d5b453ad1203f85cc5421b96ed6ebcc2f2299	start_cd.elf

and the following settings in config.txt:

[pi3]
kernel=../../sys/src/9/bcm/9pi2

[all]
gpu_mem=16
enable_uart=1
boot_delay=1

note that atags worked just fine for me, without any
special setting.

so can you tell me exactly what you are doing?

because i can't reproduce anything you described.

--
cinap

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-11 12:11                 ` cinap_lenrek
@ 2021-04-12  9:04                   ` Daniel Morandini
  2021-04-12 10:14                     ` cinap_lenrek
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-04-12  9:04 UTC (permalink / raw)
  To: 9front

Good morning cinap!

> ok, i just tried the 32 bit pi2 kernel with a raspberry pi 3B+ 
> pxeboot and the R2 register appears to be zero on entry.
I stumbled upon the R2 thing just by reading the docs and as I was
debugging my issue I thought the docs/comments mismatch might have
been an hint.

I did not double-check it as:
- I don't know yet how to access a register (:D) (is KADDR giving a 
pointer to it? What if I give it 2 instead of 0?), and 
- I assumed `if(pa != 0 && /* smth */` is never asserted as pa is
apparently always 0.

If I call bootargsinit(2) which calls KADDR(2) is yielding R2, I just
checked it and (without device_tree= in config.txt, otherwise the
fallback works and the Pi loads the args) the Pi is *NOT* loading
neither devtree nor atags: I assume you’re right then? No R2 for
Pis?

I’ll be on it later this afternoon.

Why the ‘pa != 0’ check?

---

Mine is a Raspberry Pi 2 Model B V1.1 (BCM2836)!
> this is with the latest bootcode.bin and start_cd*.elf:
> 
> term% sha1sum bootcode.bin fixup_cd.dat start_cd.elf
> 76b71ff97ace39d9900c27f761f7548c4c6f49a5	bootcode.bin
> 1585386a20cfc42b541f3ed1439d90e8c5b4529e	fixup_cd.dat
> e08d5b453ad1203f85cc5421b96ed6ebcc2f2299	start_cd.elf
filefucker# sha1sum bootcode.bin start_cd.elf fixup_cd.dat
0f3e37fdc441fcb20fbd746978e05386acfdf876	bootcode.bin
b2af5034d792c5baaa6a8897f9ac24d308e66026	start_cd.elf
72522c2c4bc18d7bea76c40a6b4330cd0f2bd52a	fixup_cd.dat

Apparently we’re using different stuff :D

> and the following settings in config.txt:
> 
> [pi3]
> kernel=../../sys/src/9/bcm/9pi2
> 
> [all]
> gpu_mem=16
> enable_uart=1
> boot_delay=1
Mine is:
kernel=9pi2
device_tree=
gpu_mem=16
enable_uart=1
uart_2ndstage=1

> note that atags worked just fine for me, without any
> special setting.
Just to learn something from a master, how are you debugging this?
I’m collecting data and dumping it as soon as print is ready!

Cheers,
dan


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-12  9:04                   ` Daniel Morandini
@ 2021-04-12 10:14                     ` cinap_lenrek
  2021-04-12 16:48                       ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-04-12 10:14 UTC (permalink / raw)
  To: 9front


> > ok, i just tried the 32 bit pi2 kernel with a raspberry pi 3B+ 
> > pxeboot and the R2 register appears to be zero on entry.

> I stumbled upon the R2 thing just by reading the docs and as I was
> debugging my issue I thought the docs/comments mismatch might have
> been an hint.

> I did not double-check it as:
> - I don't know yet how to access a register (:D) (is KADDR giving a 
> pointer to it? What if I give it 2 instead of 0?), and 

nonono. you have to save the R2 register on entry and get it to
main. see the diff later.

> - I assumed `if(pa != 0 && /* smth */` is never asserted as pa is
> apparently always 0.

of course, we always call bootargsinit(0) in the 32 bit bcm kernel.
that is a constant.

> If I call bootargsinit(2) which calls KADDR(2) is yielding R2, I just
> checked it and (without device_tree= in config.txt, otherwise the
> fallback works and the Pi loads the args) the Pi is *NOT* loading
> neither devtree nor atags: I assume you’re right then? No R2 for
> Pis?

nononono. KADDR() translates a physical address to the KZERO window
of the kernel. like physical address 0 becomes (KZERO+0)... this
for accessing memory (reading the DTB/ATAGS).

> I’ll be on it later this afternoon.

> Why the ‘pa != 0’ check?

i already said that bootargs.c in bcm/ is shared also by the bcm64
kernel, where we pass the dtb pointer to it. but it is not used in
the 32 bit bcm kernel. that is why there is a conditional. a pa
of 0 means the address is not valid. its like a NULL check.

theres also a special case that ATAGS are trashed on kernel-to-kernel
reboot. so even on bcm64, pa can be 0 when the information has been
converted to CONFADDR text block.

> Just to learn something from a master, how are you debugging this?
> I’m collecting data and dumping it as soon as print is ready!

thats pretty much how you do it.

anyway, heres how i checked what R2 is on entry. basically,
move R2 to R10 (which is reserved by c code for the mach
pointer so c code wont trash it). and then before calling
main() put it in R0 (first arument).

diff -r b4182c0fe4a9 sys/src/9/bcm/armv6.s
--- a/sys/src/9/bcm/armv6.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/armv6.s	Mon Apr 12 11:58:27 2021 +0200
@@ -76,6 +76,9 @@
 	MOVW	$1, R1
 	MCR	CpSC, 0, R1, C(CpSPM), C(CpSPMperf), CpSPMctl
 
+	/* first arg to main is saved R2 */
+	MOVW	R10, R0
+
 	/*
 	 * call main and loop forever if it returns
 	 */
diff -r b4182c0fe4a9 sys/src/9/bcm/armv7.s
--- a/sys/src/9/bcm/armv7.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/armv7.s	Mon Apr 12 11:58:27 2021 +0200
@@ -126,6 +126,9 @@
 	MOVW	$1, R1
 	MCR	CpSC, 0, R1, C(CpCLD), C(CpCLDena), CpCLDenapmnc
 
+	/* first arg to main is saved R2 */
+	MOVW	R10, R0
+
 	/*
 	 * call main and loop forever if it returns
 	 */
diff -r b4182c0fe4a9 sys/src/9/bcm/bootargs.c
--- a/sys/src/9/bcm/bootargs.c	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/bootargs.c	Mon Apr 12 11:58:27 2021 +0200
@@ -265,7 +265,7 @@
 	uintptr len;
 
 	/*
-	 * kernel gets DTB/ATAGS pointer in R0 on entry
+	 * kernel gets DTB/ATAGS pointer on entry
 	 */
 	if(pa != 0 && (len = cankaddr(pa)) != 0){
 		void *va = KADDR(pa);
diff -r b4182c0fe4a9 sys/src/9/bcm/l.s
--- a/sys/src/9/bcm/l.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/l.s	Mon Apr 12 11:58:27 2021 +0200
@@ -10,6 +10,9 @@
  * other cpus enter at cpureset in armv7.s
  */
 TEXT _start(SB), 1, $-4
+	/* save R2 in extern register R10 (Mach *m) */
+	MOVW	R2, R10
+
 	/*
 	 * load physical base for SB addressing while mmu is off
 	 * keep a handy zero in R0 until first function call
diff -r b4182c0fe4a9 sys/src/9/bcm/main.c
--- a/sys/src/9/bcm/main.c	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/main.c	Mon Apr 12 11:58:27 2021 +0200
@@ -75,7 +75,7 @@
 }
 
 void
-main(void)
+main(uintptr arg0)
 {
 	extern char edata[], end[];
 	uint fw, board;
@@ -90,6 +90,8 @@
 	uartconsinit();
 	screeninit();
 
+	print("arg0 = %#p\n", arg0);
+
 	print("\nPlan 9 from Bell Labs\n");
 	board = getboardrev();
 	fw = getfirmware();
diff -r b4182c0fe4a9 sys/src/9/bcm/rebootcode.s
--- a/sys/src/9/bcm/rebootcode.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/rebootcode.s	Mon Apr 12 11:58:27 2021 +0200
@@ -84,6 +84,7 @@
 	BEQ	dowfi		/* if zero, wait again */
 
 bootcpu:
+	MOVW	$0, R2		/* no ATAGS/DTB pointer */
 	BIC	$KSEGM, R8	/* entry to physical */
 	ORR	$PHYSDRAM, R8
 	BL	(R8)

--
cinap

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-12 10:14                     ` cinap_lenrek
@ 2021-04-12 16:48                       ` Daniel Morandini
  2021-04-15 21:15                         ` cinap_lenrek
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-04-12 16:48 UTC (permalink / raw)
  To: 9front

> nonono. you have to save the R2 register on entry and get it to
> main. see the diff later.
> 
> nononono. KADDR() translates a physical address to the KZERO window
> of the kernel. like physical address 0 becomes (KZERO+0)... this
> for accessing memory (reading the DTB/ATAGS).
Sorry for these stupid questions, the code really is self explanatory

> i already said that bootargs.c in bcm/ is shared also by the bcm64
> kernel, where we pass the dtb pointer to it. but it is not used in
> the 32 bit bcm kernel. that is why there is a conditional. a pa
> of 0 means the address is not valid. its like a NULL check.

> theres also a special case that ATAGS are trashed on kernel-to-kernel
> reboot. so even on bcm64, pa can be 0 when the information has been
> converted to CONFADDR text block.
All clear now.

>> Just to learn something from a master, how are you debugging this?
>> I’m collecting data and dumping it as soon as print is ready!
> 
> thats pretty much how you do it.
> 
> anyway, heres how i checked what R2 is on entry. basically,
> move R2 to R10 (which is reserved by c code for the mach
> pointer so c code wont trash it). and then before calling
> main() put it in R0 (first arument).
This is so cool cinap, thank you for sharing! *.*

With patch attached and a `bootargsinit(arg0)` instead of 0 that’s
it, issue solved without `device_tree=` option! The fw loads a dtree
and we correctly load it from the proper address!

Cheers,
dan

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-12 16:48                       ` Daniel Morandini
@ 2021-04-15 21:15                         ` cinap_lenrek
  2021-04-19  7:53                           ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: cinap_lenrek @ 2021-04-15 21:15 UTC (permalink / raw)
  To: 9front

so you confirm that the following patch works? because
i could not reproduce it on the PI3B+ (R2 always 0).

--
cinap

PATCH:

diff -r b4182c0fe4a9 sys/src/9/bcm/armv6.s
--- a/sys/src/9/bcm/armv6.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/armv6.s	Thu Apr 15 23:13:36 2021 +0200
@@ -76,6 +76,9 @@
 	MOVW	$1, R1
 	MCR	CpSC, 0, R1, C(CpSPM), C(CpSPMperf), CpSPMctl
 
+	/* first arg to main is saved R2 */
+	MOVW	R10, R0
+
 	/*
 	 * call main and loop forever if it returns
 	 */
diff -r b4182c0fe4a9 sys/src/9/bcm/armv7.s
--- a/sys/src/9/bcm/armv7.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/armv7.s	Thu Apr 15 23:13:36 2021 +0200
@@ -126,6 +126,9 @@
 	MOVW	$1, R1
 	MCR	CpSC, 0, R1, C(CpCLD), C(CpCLDena), CpCLDenapmnc
 
+	/* first arg to main is saved R2 */
+	MOVW	R10, R0
+
 	/*
 	 * call main and loop forever if it returns
 	 */
diff -r b4182c0fe4a9 sys/src/9/bcm/bootargs.c
--- a/sys/src/9/bcm/bootargs.c	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/bootargs.c	Thu Apr 15 23:13:36 2021 +0200
@@ -265,7 +265,7 @@
 	uintptr len;
 
 	/*
-	 * kernel gets DTB/ATAGS pointer in R0 on entry
+	 * kernel gets DTB/ATAGS pointer on entry
 	 */
 	if(pa != 0 && (len = cankaddr(pa)) != 0){
 		void *va = KADDR(pa);
diff -r b4182c0fe4a9 sys/src/9/bcm/l.s
--- a/sys/src/9/bcm/l.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/l.s	Thu Apr 15 23:13:36 2021 +0200
@@ -10,6 +10,9 @@
  * other cpus enter at cpureset in armv7.s
  */
 TEXT _start(SB), 1, $-4
+	/* save R2 in extern register R10 (Mach *m) */
+	MOVW	R2, R10
+
 	/*
 	 * load physical base for SB addressing while mmu is off
 	 * keep a handy zero in R0 until first function call
diff -r b4182c0fe4a9 sys/src/9/bcm/main.c
--- a/sys/src/9/bcm/main.c	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/main.c	Thu Apr 15 23:13:36 2021 +0200
@@ -75,7 +75,7 @@
 }
 
 void
-main(void)
+main(uintptr arg0)
 {
 	extern char edata[], end[];
 	uint fw, board;
@@ -84,7 +84,7 @@
 	memset(edata, 0, end - edata);	/* clear bss */
 	mach0init();
 	quotefmtinstall();
-	bootargsinit(0);
+	bootargsinit(arg0);
 	confinit();		/* figures out amount of memory */
 	xinit();
 	uartconsinit();
diff -r b4182c0fe4a9 sys/src/9/bcm/rebootcode.s
--- a/sys/src/9/bcm/rebootcode.s	Sun Apr 11 23:58:30 2021 +0200
+++ b/sys/src/9/bcm/rebootcode.s	Thu Apr 15 23:13:36 2021 +0200
@@ -84,6 +84,7 @@
 	BEQ	dowfi		/* if zero, wait again */
 
 bootcpu:
+	MOVW	$0, R2		/* no ATAGS/DTB pointer */
 	BIC	$KSEGM, R8	/* entry to physical */
 	ORR	$PHYSDRAM, R8
 	BL	(R8)


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-15 21:15                         ` cinap_lenrek
@ 2021-04-19  7:53                           ` Daniel Morandini
  2021-04-19 16:20                             ` Daniel Morandini
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel Morandini @ 2021-04-19  7:53 UTC (permalink / raw)
  To: 9front

> so you confirm that the following patch works? because
> i could not reproduce it on the PI3B+ (R2 always 0).
Hi cinap,
I discarded my changes and updated to b31369df5d7d.  I double checked
that WITHOUT your changes the issue persists on the bcm boards I
have (a pi and pi2 model b), and it is CONFIRMED.

I was going to apply your patch and test the fix, but `hg import
—-no-commit -f <your patch>` refuses to apply it!  The .rej files
do not contain anything useful, to me they just show the patch is
perfectly fine. I also tried the `—-exact` flag and `—-import-branch`.

Sorry if this is answered elsewhere but I’m a bit in a hurry, I’ll be
back on it this afternoon. (I’m used to git and Go)

Cheers,
dan

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9front] PXE booting Rpi
  2021-04-19  7:53                           ` Daniel Morandini
@ 2021-04-19 16:20                             ` Daniel Morandini
  0 siblings, 0 replies; 17+ messages in thread
From: Daniel Morandini @ 2021-04-19 16:20 UTC (permalink / raw)
  To: 9front

>> so you confirm that the following patch works? because
>> i could not reproduce it on the PI3B+ (R2 always 0).
> Hi cinap,
> I discarded my changes and updated to b31369df5d7d.  I double checked
> that WITHOUT your changes the issue persists on the bcm boards I
> have (a pi and pi2 model b), and it is CONFIRMED.
> 
> I was going to apply your patch and test the fix, but `hg import
> —-no-commit -f <your patch>` refuses to apply it!  The .rej files
> do not contain anything useful, to me they just show the patch is
> perfectly fine. I also tried the `—-exact` flag and `—-import-branch`.
In the meanwhile I applied the changes manually. Your patch works,
R2 is NOT zero on these devices!

Cheers,
dan

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-04-19 16:27 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 14:05 [9front] PXE booting Rpi Daniel Morandini
2021-03-10 17:20 ` cinap_lenrek
2021-03-12 10:36   ` Daniel Morandini
2021-03-25 10:55     ` Daniel Morandini
2021-03-25 18:49       ` Noam Preil
2021-03-25 21:49         ` Noam Preil
2021-04-07  8:39         ` Daniel Morandini
2021-04-08 14:21           ` cinap_lenrek
2021-04-08 15:45             ` Daniel Morandini
2021-04-08 16:12               ` cinap_lenrek
2021-04-11 12:11                 ` cinap_lenrek
2021-04-12  9:04                   ` Daniel Morandini
2021-04-12 10:14                     ` cinap_lenrek
2021-04-12 16:48                       ` Daniel Morandini
2021-04-15 21:15                         ` cinap_lenrek
2021-04-19  7:53                           ` Daniel Morandini
2021-04-19 16:20                             ` Daniel Morandini

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