search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.18k stars 1.68k forks source link

PXE Boot wont work with RPi 3 #859

Closed unix0r closed 6 years ago

unix0r commented 7 years ago

Hey Guys,, I'm trying to boot a Raspberry Pi 3 via Network but it does not work.

I followed the instructions of the raspberry pi blog. The Pi is configured to boot 

pi@pxe:~ $ vcgencmd otp_dump | grep 17:
17:3020000a

The TFTP Server shows on a folder that contains all files from /boot (copied) and a NFS Server serves the root Filesystem. The /etc/fstab contains only /proc and the cmdline.txt shows on the nfs server:

port=0
dhcp-range=192.168.0.255,proxy
log-dhcp
enable-tftp
tftp-root=/tftpboot
pxe-service=0,"Raspberry Pi Boot"

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.0.2:/nfs/client1 rw ip=dhcp rootwait elevator=deadline

The booting Pi is requesting the files:

11:52:03.620870 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 49) 192.168.0.103.49152 > 192.168.0.2.tftp: 21 RRQ "bootcode.bin" octet 11:52:03.670327 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 48) 192.168.0.103.49152 > 192.168.0.2.tftp: 20 RRQ "bootsig.bin" octet 11:52:05.778664 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57) 192.168.0.103.49154 > 192.168.0.2.tftp: 29 RRQ "autoboot.txt" octet tsize 0 11:52:06.778753 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 55) 192.168.0.103.49155 > 192.168.0.2.tftp: 27 RRQ "config.txt" octet tsize 0 11:52:07.779113 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57) 192.168.0.103.49156 > 192.168.0.2.tftp: 29 RRQ "recovery.elf" octet tsize 0 11:52:09.646980 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54) 192.168.0.103.49157 > 192.168.0.2.tftp: 26 RRQ "start.elf" octet tsize 0 11:52:10.647108 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54) 192.168.0.103.49158 > 192.168.0.2.tftp: 26 RRQ "fixup.dat" octet tsize 0

But the TFTP Server only serves the bootcode.bin:

Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 available DHCP subnet: 192.168.0.255/255.255.255.0 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 PXE(eth0) b8:27:eb:f4:bb:43 proxy Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 tags: eth0 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 bootfile name: bootcode.bin Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 broadcast response Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 sent size: 1 option: 53 message-type 2 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 sent size: 4 option: 54 server-identifier 192.168.0.2 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 sent size: 17 option: 97 client-machine-id 00:44:44:44:44:44:44:44:44:44:44:44:44:44... Aug 9 12:13:01 pxe dnsmasq-dhcp[618]: 653460281 sent size: 32 option: 43 vendor-encap 06:01:03:0a:04:00:50:58:45:09:14:00:00:11... Aug 9 12:16:15 pxe dnsmasq-tftp[618]: file /tftpboot/bootsig.bin not found Aug 9 12:16:15 pxe dnsmasq-tftp[618]: sent /tftpboot/bootcode.bin to 192.168.0.103

After that, the ACT LED is blinking, but the RPi is not booted correctly. I tried it also with the new raspbian stretch today. Can anyone help?

Thank you

ghollingworth commented 7 years ago

What is the led blinking pattern, 4 flashes, 4 long +4 short etc?

Assuming it's 4 flashes which means can't load start.elf

But it does look like dnsmasq is ignoring the subsequent requests for files, wondering whether the version has changed for stretch...

Gordon

unix0r commented 7 years ago

The blinking pattern is 4 long and 4 short. I tried it with dnsmasq as a tftp server with the default version of raspbian jessi, stretch and with the newest version of the website. I also tried it with atftpd, but it resulted in the same behaviour.

The start.elf file is located in the /tftpboot directory:

pi@pxe:~ $ ls -l /tftpboot/ total 21232 -rwxr-xr-x 1 pi pi 15660 Aug 21 09:04 bcm2708-rpi-0-w.dtb -rwxr-xr-x 1 pi pi 15197 Aug 21 09:04 bcm2708-rpi-b.dtb -rwxr-xr-x 1 pi pi 15456 Aug 21 09:04 bcm2708-rpi-b-plus.dtb -rwxr-xr-x 1 pi pi 14916 Aug 21 09:04 bcm2708-rpi-cm.dtb -rwxr-xr-x 1 pi pi 16523 Aug 21 09:04 bcm2709-rpi-2-b.dtb -rwxr-xr-x 1 pi pi 17624 Aug 21 09:04 bcm2710-rpi-3-b.dtb -rwxr-xr-x 1 pi pi 16380 Aug 21 09:04 bcm2710-rpi-cm3.dtb -rwxr-xr-x 1 pi pi 50248 Aug 21 09:04 bootcode.bin -rwxr-xr-x 1 pi pi 142 Aug 21 09:49 cmdline.txt -rwxr-xr-x 1 pi pi 1614 Aug 21 09:04 config.txt -rwxr-xr-x 1 pi pi 18693 Aug 21 09:04 COPYING.linux -rwxr-xr-x 1 pi pi 2594 Aug 21 09:04 fixup_cd.dat -rwxr-xr-x 1 pi pi 6688 Aug 21 09:04 fixup.dat -rwxr-xr-x 1 pi pi 9834 Aug 21 09:04 fixup_db.dat -rwxr-xr-x 1 pi pi 9830 Aug 21 09:04 fixup_x.dat -rwxr-xr-x 1 pi pi 145 Aug 21 09:04 issue.txt -rwxr-xr-x 1 pi pi 4581264 Aug 21 09:04 kernel7.img -rwxr-xr-x 1 pi pi 4380840 Aug 21 09:04 kernel.img -rwxr-xr-x 1 pi pi 1494 Aug 21 09:04 LICENCE.broadcom -rwxr-xr-x 1 pi pi 18974 Aug 21 09:04 LICENSE.oracle drwxr-xr-x 2 pi pi 4096 Aug 21 09:04 overlays -rwxr-xr-x 1 pi pi 666404 Aug 21 09:04 start_cd.elf -rwxr-xr-x 1 pi pi 5007204 Aug 21 09:04 start_db.elf -rwxr-xr-x 1 pi pi 2868132 Aug 21 09:04 start.elf -rwxr-xr-x 1 pi pi 3952100 Aug 21 09:04 start_x.elf

ghollingworth commented 7 years ago

Can you tcpdump everything to a cap file?

Gordon

unix0r commented 7 years ago

Here is the trace file: trace3.zip

ghollingworth commented 7 years ago

That doesn't contain the replies to the tftp requests, what filter did you put on there?

Gordon

ghollingworth commented 7 years ago

Also it might be worth seeing how it works with dnsmasq v2.77

git clone git://thekelleys.org.uk/dnsmasq.git cd dnsmasq make sudo make install

Should do it... This has a couple of new options:

--dhcp-reply-delay=2

This will delay the dhcp reply from dnsmasq for two seconds so it appears after the standard IP address response. This will stop the Pi from getting stuck in a timeout loop!

Gordon

unix0r commented 7 years ago

The filter was: sudo tcpdump -i enxb827ebf4bb43 port not ssh -w trace3.cap

and the behaviour with --dhcp-reply-delay=2 is the same.

Aug 22 06:53:55 pxe dnsmasq-dhcp[1055]: 653460281 available DHCP subnet: 192.168.5.255/255.255.255.0 Aug 22 06:53:55 pxe dnsmasq-dhcp[1055]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001 Aug 22 06:53:55 pxe dnsmasq-dhcp[1055]: 653460281 PXE(enxb827ebf4bb43) b8:27:eb:7a:ec:5c proxy Aug 22 06:53:55 pxe dnsmasq-dhcp[1055]: 653460281 tags: enxb827ebf4bb43 Aug 22 06:53:55 pxe dnsmasq-dhcp[1055]: 653460281 reply delay: 2 Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 broadcast response Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 sent size: 1 option: 53 message-type 2 Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 sent size: 4 option: 54 server-identifier 192.168.5.2 Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 sent size: 17 option: 97 client-machine-id 00:44:44:44:44:44:44:44:44:44:44:44:44:44... Aug 22 06:53:57 pxe dnsmasq-dhcp[1055]: 653460281 sent size: 32 option: 43 vendor-encap 06:01:03:0a:04:00:50:58:45:09:14:00:00:11... Aug 22 06:53:57 pxe dnsmasq-tftp[1055]: sent /tftpboot/bootcode.bin to 192.168.5.101 Aug 22 06:53:57 pxe dnsmasq-tftp[1055]: file /tftpboot/bootsig.bin not found

06:53:55.448652 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b8:27:eb:7a:ec:5c (oui Unknown), length 320 06:53:55.466281 IP 192.168.5.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548 06:53:57.452464 IP 192.168.5.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 314 06:53:57.453383 IP 192.168.5.101.49152 > 192.168.5.2.tftp: 21 RRQ "bootcode.bin" octet 06:53:57.503575 IP 192.168.5.101.49152 > 192.168.5.2.tftp: 20 RRQ "bootsig.bin" octet 06:53:59.611725 IP 192.168.5.101.49154 > 192.168.5.2.tftp: 29 RRQ "autoboot.txt" octet tsize 0 06:54:00.611813 IP 192.168.5.101.49155 > 192.168.5.2.tftp: 27 RRQ "config.txt" octet tsize 0 06:54:01.612184 IP 192.168.5.101.49156 > 192.168.5.2.tftp: 29 RRQ "recovery.elf" octet tsize 0 06:54:02.612196 IP 192.168.5.101.49157 > 192.168.5.2.tftp: 26 RRQ "start.elf" octet tsize 0 06:54:04.006761 IP 192.168.5.101.49158 > 192.168.5.2.tftp: 26 RRQ "fixup.dat" octet tsize 0

Thank you for your help.

ghollingworth commented 7 years ago

Ah, OK, looking at the packets it looks like the ethernet address is broken in the 2nd stage, for some reason it starts writing to address 00:00:00:00:00:00 which is why the server doesn't respond.

Not sure if this is something that has broken in the latest bootcode.bin build or if it's something about your network which causes it... Might be worth going back a couple of months and downloading bootcode.bin directly from github to see if it changed at all in the last six months or so.

I'll have a look at it tomorrow when I'm back in the office

unix0r commented 7 years ago

yeah i think it is caused by the switch. I tried it with several different switches and all showed the same behaviour. But i tested it with a direct connection between RPi and PXE RPi now and it works!

ghollingworth commented 7 years ago

Can you try again with the attached bootcode.bin (put it into the tftpboot directory), I think the problem is that the arp messages from the client Raspberry Pi are going missing... If you can throw this one into the tftpboot directory:

bootcode.zip

It should now output debug messages on pin 8 of the GPIO connector, if you've got a suitable serial adapter?

If not then just tcpdump it, a failed ARP will show up as an ethernet address of aa:aa:aa:aa:aa:aa

Gordon

unix0r commented 7 years ago

A quickt test shows, that the ethernet addresses are all aa:aa:aa:aa:aa:aa after the bootcode.bin was delivered an bootsig failed. So the booting pi cant connect to the pxe server. But connected to the same unmanaged switch the pi boots normally but then the filesystem cant be mounted as in issue: https://github.com/raspberrypi/firmware/issues/863

ghollingworth commented 7 years ago

OK, so looks like the managed switch is filtering your ARP requests out for some reason, I wonder if this is another problem with the STP. (Or a problem with the ARP, although the ARP packet looks valid...)

You could try disabling STP in the switch to see if this is the problem although it's strange that it is only filtering this one packet type...

Gordon

fedorovvl commented 7 years ago

I have same problem with cisco SF220 switch. boot process stop after bootsig.bin requested

22:31:33.534055 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 348) 0.0.0.0.bootpc > 255.255.255.255.bootps: [no cksum] BOOTP/DHCP, Request from b8:27:eb:1c:ff:5b (oui Unknown), length 320, xid 0x26f30339, Flags [none] (0x0000) Client-Ethernet-Address b8:27:eb:1c:ff:5b (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 12: Vendor-Option, Vendor-Class, BF, Option 128 Option 129, Option 130, Option 131, Option 132 Option 133, Option 134, Option 135, TFTP ARCH Option 93, length 2: 0 NDI Option 94, length 3: 1.2.1 GUID Option 97, length 17: 0.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68 Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001" END Option 255, length 0 22:31:33.534331 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell mge-smoapp, length 28 22:31:34.535505 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) mge-smoapp.bootps > 192.168.0.3.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x26f30339, Flags [none] (0x0000) Your-IP 192.168.0.3 Server-IP mge-smoapp Client-Ethernet-Address b8:27:eb:1c:ff:5b (oui Unknown) file "pxelinux.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: mge-smoapp Lease-Time Option 51, length 4: 600 Vendor-Option Option 43, length 12: 49.57.50.46.49.54.56.46.48.46.49.48 TFTP Option 66, length 20: "Raspberry Pi Boot " Subnet-Mask Option 1, length 4: 255.255.255.0 END Option 255, length 0 PAD Option 0, length 0, occurs 2 22:31:34.536221 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has mge-smoapp tell 192.168.0.3, length 46 22:31:34.536250 IP (tos 0x0, ttl 64, id 13831, offset 0, flags [DF], proto ICMP (1), length 48) mge-smoapp > 192.168.0.3: ICMP echo request, id 24591, seq 0, length 28 22:31:34.536260 ARP, Ethernet (len 6), IPv4 (len 4), Reply mge-smoapp is-at 00:15:5d:2a:54:16 (oui Unknown), length 28 22:31:34.536567 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 49) 192.168.0.3.49152 > mge-smoapp.tftp: [no cksum] 21 RRQ "bootcode.bin" octet 22:31:34.540613 IP (tos 0x0, ttl 64, id 19468, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x2b38!] UDP, length 516 22:31:34.540995 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.541037 IP (tos 0x0, ttl 64, id 19469, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x5fc7!] UDP, length 516 22:31:34.541316 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.541351 IP (tos 0x0, ttl 64, id 19470, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x6da6!] UDP, length 516 22:31:34.541634 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.541676 IP (tos 0x0, ttl 64, id 19471, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x41af!] UDP, length 516 22:31:34.542031 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.542052 IP (tos 0x0, ttl 64, id 19472, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x064b!] UDP, length 516 22:31:34.542312 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.542340 IP (tos 0x0, ttl 64, id 19473, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x390a!] UDP, length 516 22:31:34.542617 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.542637 IP (tos 0x0, ttl 64, id 19474, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0xbc6a!] UDP, length 516 22:31:34.542913 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.542935 IP (tos 0x0, ttl 64, id 19475, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x5308!] UDP, length 516 22:31:34.543185 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.543215 IP (tos 0x0, ttl 64, id 19476, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x7e02!] UDP, length 516 22:31:34.543472 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.543499 IP (tos 0x0, ttl 64, id 19477, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x5ec4!] UDP, length 516 22:31:34.543769 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.543799 IP (tos 0x0, ttl 64, id 19478, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0xe5c3!] UDP, length 516 22:31:34.544056 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.544089 IP (tos 0x0, ttl 64, id 19479, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x16e5!] UDP, length 516 22:31:34.544390 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.544415 IP (tos 0x0, ttl 64, id 19480, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x35c7!] UDP, length 516 .... 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.577500 IP (tos 0x0, ttl 64, id 19562, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x2ada!] UDP, length 516 22:31:34.577903 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.577997 IP (tos 0x0, ttl 64, id 19563, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x2ad9!] UDP, length 516 22:31:34.578338 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.578429 IP (tos 0x0, ttl 64, id 19564, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x22f9!] UDP, length 516 22:31:34.579008 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.579099 IP (tos 0x0, ttl 64, id 19565, offset 0, flags [none], proto UDP (17), length 544) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x837b -> 0x233c!] UDP, length 516 22:31:34.579455 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.579518 IP (tos 0x0, ttl 64, id 19566, offset 0, flags [none], proto UDP (17), length 124) mge-smoapp.36667 > 192.168.0.3.49152: [bad udp cksum 0x81d7 -> 0xa1af!] UDP, length 96 22:31:34.579708 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32) 192.168.0.3.49152 > mge-smoapp.36667: [no cksum] UDP, length 4 22:31:34.579709 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 48) 192.168.0.3.49152 > mge-smoapp.tftp: [no cksum] 20 RRQ "bootsig.bin" octet 22:31:34.580462 IP (tos 0x0, ttl 64, id 19567, offset 0, flags [none], proto UDP (17), length 47) mge-smoapp.59240 > 192.168.0.3.49152: [bad udp cksum 0x818a -> 0x95f9!] UDP, length 19 22:31:39.540730 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell mge-smoapp, length 28 22:31:40.542721 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell mge-smoapp, length 28 22:31:41.544711 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.3 tell mge-smoapp, length 28

Disabling stp globally didn't help. with cisco catalist 2960 all work, and without sf220 all work too ) with bootcode.bin from comment above i see in console without sf220:

Raspberry Pi Bootcode

Done ARP for 10.0.168.192 got 00:15:5d:2a:54:16 Read File: config.txt, 495 (bytes)

Raspberry Pi Bootcode Read File: config.txt, 495 Read File: start.elf, 2848836 (bytes) Read File: fixup.dat, 6644 (bytes)

with sf220:

Raspberry Pi Bootcode

No response from ARP request

Raspberry Pi Bootcode

How else can I try to bring it to work?

[added] new info .. rpi restart network interface after bootcode.bin, and switch can not be in time to up interface, so arp request losted and boot break. if i attach hub between cisco and rpi all work :/ it possible to add some delay between init interface and send packets on rpi? or maybe duplicate request 2-3 times if last fails?

fedorovvl commented 7 years ago

ghollingworth, can you modify bootcode.bin for my with mac 00:15:5d:2a:54:16 instead aa:aa:aa or tell me how you doing this? [added] I change mac on server to AA:AA:AA:AA:AA:AA and all work now lol =))

unix0r commented 7 years ago

I was trying it with unmanaged switches.

@fedorovvl The Bootcode.bin was just for research purpose only to see if the problem is associated with the failing ARP requests.

aaronk6 commented 6 years ago

@unix0r Were you able to solve this? I think I’m seeing the same issue.

The tftp server only sees requests for bootcode.bin and bootsig.bin:

# tail -f /var/log/syslog
Mar 28 23:47:53 homeserver-new tftpd[2970]: tftpd: trying to get file: bootcode.bin
Mar 28 23:47:53 homeserver-new tftpd[2970]: tftpd: serving file from /tftpboot
Mar 28 23:47:53 homeserver-new tftpd[2972]: tftpd: trying to get file: bootsig.bin
Mar 28 23:47:53 homeserver-new tftpd[2972]: tftpd: serving file from /tftpboot

The Pi seems to request the other files, but apparently those requests don’t reach the tftp server:

sudo tcpdump -vvv -i switch0 ether host b8:27:eb:fc:55:61
23:47:47.353551 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.0.2.254.bootps > led-pi.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x26f30339, Flags [none] (0x0000)
      Your-IP led-pi
      Client-Ethernet-Address b8:27:eb:fc:55:61 (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.0.2.254
        Lease-Time Option 51, length 4: 86400
        Vendor-Option Option 43, length 20: 82.97.115.112.98.101.114.114.121.32.80.105.32.66.111.111.116.32.32.32
        TFTP Option 66, length 10: "10.0.2.159"
        Subnet-Mask Option 1, length 4: 255.255.255.0
        END Option 255, length 0
        PAD Option 0, length 0, occurs 4
23:47:53.254391 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has homeserver-new tell led-pi, length 46
23:47:55.976362 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    led-pi.49154 > homeserver-new.tftp: [no cksum]  29 RRQ "autoboot.txt" octet tsize 0
23:47:57.355621 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 55)
    led-pi.49155 > homeserver-new.tftp: [no cksum]  27 RRQ "config.txt" octet tsize 0
23:47:59.267729 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    led-pi.49156 > homeserver-new.tftp: [no cksum]  29 RRQ "recovery.elf" octet tsize 0
23:48:00.939198 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    led-pi.49157 > homeserver-new.tftp: [no cksum]  26 RRQ "start.elf" octet tsize 0
23:48:01.939333 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    led-pi.49158 > homeserver-new.tftp: [no cksum]  26 RRQ "fixup.dat" octet tsize 0

I have a managed switch (Ubiquiti EdgeSwitch 8-port). I’ve disabled STP, as I read in another thread that this could potentially cause issues. A similar setup (without a managed switch though) was working for me a couple of month ago. So I believe it’s somehow related to the managed switch.

I’ll try to narrow this down by replacing the switch, however, it would be highly appreciated if you could give me a quick update whether you made any progress on this matter! Thanks 😊

pelwell commented 6 years ago

What are homeserver-new and led-pi's IP addresses?

aaronk6 commented 6 years ago

Hey, thanks for the quick reply! Actually I just solved this: it turned out that an old router I was using as a switch (Fritzbox 7270) was causing this. After replacing it with a standard switch, the setup works perfectly fine, even with the managed EdgeSwitch in between. Sorry for the noise! 🙈

spiderpug commented 6 years ago

Hi, I'm having a similar issue, I guess. I'm also using a FritzBox as router and my DHCP/TFTP server is a Synology NAS. This is my dump:

00:54:00.557089 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 348)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [no cksum] BOOTP/DHCP, Request from b8:27:eb:5e:4e:6d (oui Unknown), length 320, xid 0x26f30339, Flags [none] (0x0000)
      Client-Ethernet-Address b8:27:eb:5e:4e:6d (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Parameter-Request Option 55, length 12:
          Vendor-Option, Vendor-Class, BF, Option 128
          Option 129, Option 130, Option 131, Option 132
          Option 133, Option 134, Option 135, TFTP
        ARCH Option 93, length 2: 0
        NDI Option 94, length 3: 1.2.1
        GUID Option 97, length 17: 0.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68
        Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
        END Option 255, length 0
00:54:00.558437 IP (tos 0xc0, ttl 64, id 5032, offset 0, flags [none], proto UDP (17), length 406)
    ds216j.fritz.box.bootps > Xbian.fritz.box.bootpc: [bad udp cksum 0xe6fb -> 0x1d13!] BOOTP/DHCP, Reply, length 378, xid 0x26f30339, Flags [none] (0x0000)
      Your-IP Xbian.fritz.box
      Server-IP ds216j.fritz.box
      Client-Ethernet-Address b8:27:eb:5e:4e:6d (oui Unknown)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: ds216j.fritz.box
        Lease-Time Option 51, length 4: 86400
        BF Option 67, length 13: "bootcode.bin^@"
        RN Option 58, length 4: 43200
        RB Option 59, length 4: 75600
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.178.255
        TFTP Option 66, length 14: "192.168.178.2^@"
        Vendor-Class Option 60, length 9: "PXEClient"
        GUID Option 97, length 17: 0.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68.68
        Vendor-Option Option 43, length 35: 6.1.3.10.4.0.80.88.69.9.23.0.0.20.82.97.115.112.98.101.114.114.121.32.80.105.32.66.111.111.116.32.32.32.255
        END Option 255, length 0
00:54:04.331793 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 49)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  21 RRQ "bootcode.bin" octet
00:54:04.349135 IP (tos 0x0, ttl 64, id 5144, offset 0, flags [DF], proto UDP (17), length 544)
    ds216j.fritz.box.tftp > Xbian.fritz.box.49152: [bad udp cksum 0xe785 -> 0x5624!]  516 DATA block 1
00:54:04.349414 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  4 ACK block 1
00:54:04.349515 IP (tos 0x0, ttl 64, id 5145, offset 0, flags [DF], proto UDP (17), length 544)
    ds216j.fritz.box.tftp > Xbian.fritz.box.49152: [bad udp cksum 0xe785 -> 0x2bef!]  516 DATA block 2
00:54:04.349782 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  4 ACK block 2
00:54:04.349865 IP (tos 0x0, ttl 64, id 5146, offset 0, flags [DF], proto UDP (17), length 544)
    ds216j.fritz.box.tftp > Xbian.fritz.box.49152: [bad udp cksum 0xe785 -> 0x6eb2!]  516 DATA block 3
00:54:04.350138 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  4 ACK block 3
...
00:54:04.382035 IP (tos 0x0, ttl 64, id 5242, offset 0, flags [DF], proto UDP (17), length 108)
    ds216j.fritz.box.tftp > Xbian.fritz.box.49152: [bad udp cksum 0xe5d1 -> 0x9c32!]  80 DATA block 99
00:54:04.382212 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  4 ACK block 99
00:54:04.382236 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 48)
    Xbian.fritz.box.49152 > ds216j.fritz.box.tftp: [no cksum]  20 RRQ "bootsig.bin" octet
00:54:04.383259 IP (tos 0x0, ttl 64, id 5243, offset 0, flags [DF], proto UDP (17), length 55)
    ds216j.fritz.box.tftp > Xbian.fritz.box.49152: [bad udp cksum 0xe59c -> 0xa434!]  27 ERROR ENOTFOUND "No Such File/No Access"
00:54:07.340818 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    Xbian.fritz.box.49154 > ds216j.fritz.box.tftp: [no cksum]  29 RRQ "autoboot.txt" octet tsize 0
00:54:09.351138 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 55)
    Xbian.fritz.box.49155 > ds216j.fritz.box.tftp: [no cksum]  27 RRQ "config.txt" octet tsize 0
00:54:10.732272 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    Xbian.fritz.box.49156 > ds216j.fritz.box.tftp: [no cksum]  29 RRQ "recovery.elf" octet tsize 0
00:54:11.732270 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    Xbian.fritz.box.49157 > ds216j.fritz.box.tftp: [no cksum]  26 RRQ "start.elf" octet tsize 0
00:54:12.732382 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    Xbian.fritz.box.49158 > ds216j.fritz.box.tftp: [no cksum]  26 RRQ "fixup.dat" octet tsize 0
00:54:21.845416 IP (tos 0x0, ttl 64, id 53519, offset 0, flags [none], proto UDP (17), length 328)

after receiving the fixup.dat the pi is only blinking: 3 short, 1 very long.

I was using the boot files or the latest master and with them it stops after sending the bootcode.bin (never requests the other files).

With https://github.com/raspberrypi/firmware/issues/958#issuecomment-375692517 it produces the log above.

What else could I try? Thanks!

Edit:

I dumped the mac addresses and noticed that they are wrong for all requests after bootcode.bin:

01:34:20.023733 b8:27:eb:5e:4e:6d > 00:11:32:6e:66:08, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 32)
    192.168.178.122.49152 > 192.168.178.2.69: [no cksum]  4 ACK block 99
01:34:20.023756 b8:27:eb:5e:4e:6d > 00:11:32:6e:66:08, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 48)
    192.168.178.122.49152 > 192.168.178.2.69: [no cksum]  20 RRQ "bootsig.bin" octet
01:34:20.024298 00:11:32:6e:66:08 > b8:27:eb:5e:4e:6d, ethertype IPv4 (0x0800), length 69: (tos 0x0, ttl 64, id 5313, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.178.2.69 > 192.168.178.122.49152: [bad udp cksum 0xe602 -> 0xa3ce!]  27 ERROR ENOTFOUND "No Such File/No Access"
01:34:23.065096 b8:27:eb:5e:4e:6d > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 71: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    192.168.178.122.49154 > 192.168.178.2.69: [no cksum]  29 RRQ "autoboot.txt" octet tsize 0
01:34:24.232091 b8:27:eb:5e:4e:6d > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 69: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 55)
    192.168.178.122.49155 > 192.168.178.2.69: [no cksum]  27 RRQ "config.txt" octet tsize 0
01:34:25.232412 b8:27:eb:5e:4e:6d > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 71: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 57)
    192.168.178.122.49156 > 192.168.178.2.69: [no cksum]  29 RRQ "recovery.elf" octet tsize 0
01:34:26.232504 b8:27:eb:5e:4e:6d > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.122.49157 > 192.168.178.2.69: [no cksum]  26 RRQ "start.elf" octet tsize 0
01:34:28.228518 b8:27:eb:5e:4e:6d > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.122.49158 > 192.168.178.2.69: [no cksum]  26 RRQ "fixup.dat" octet tsize 0

ref https://github.com/raspberrypi/firmware/issues/745

cupples commented 6 years ago

Has anyone played with the switchport ”link debounce” option on the Cisco’s? I just hit this at the office and the intermediate switche “solved” the issue, but isn’t a solution. I may try poking at it this weekend at home but thought it was worth asking first.

paulenuta commented 6 years ago

I have a similar issue. [Solved by making a simple private network for the PXE environment] I read and apply: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md

I am using „Linux nfs-pi 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux” from 2018-10-09-raspbian-stretch-lite.zip. My network has a Linux gateway for the internet and a windows 2k8R2 server for dhcp and dns, plus a managed switch, plus, on my bench, an unmanaged switch.

I have created folders like this:

root@nfs-pi:/home/pi# ls -al /tftpboot/
total 22156
drwxrwxrwx  5 root root    4096 Oct 18 14:48 .
drwxr-xr-x 24 root root    4096 Oct 18 09:56 ..
drwxr-xr-x  3 root root    4096 Oct 18 14:48 000000005e5a8e32
drwxr-xr-x  3 root root    4096 Oct 18 14:48 5e5a8e32
-rwxr-xr-x  1 root root   23315 Sep 19 21:06 bcm2708-rpi-0-w.dtb
-rwxr-xr-x  1 root root   22812 Sep 19 21:06 bcm2708-rpi-b.dtb
-rwxr-xr-x  1 root root   23071 Sep 19 21:06 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x  1 root root   22589 Sep 19 21:06 bcm2708-rpi-cm.dtb
-rwxr-xr-x  1 root root   24115 Sep 19 21:06 bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root root   25311 Sep 19 21:06 bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root root   25574 Sep 19 21:06 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root root   24087 Sep 19 21:06 bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root root   52116 Sep 25 12:06 bootcode.bin
-rwxr-xr-x  1 root root     142 Oct 18 08:29 cmdline.txt
-rwxr-xr-x  1 root root    1971 Oct 18 09:31 config.txt
-rwxr-xr-x  1 root root   18693 Mar  9  2018 COPYING.linux
-rwxr-xr-x  1 root root    2618 Sep 25 12:06 fixup_cd.dat
-rwxr-xr-x  1 root root    6660 Sep 25 12:06 fixup.dat
-rwxr-xr-x  1 root root    9893 Sep 25 12:06 fixup_db.dat
-rwxr-xr-x  1 root root    9889 Sep 25 12:06 fixup_x.dat
-rwxr-xr-x  1 root root     145 Oct  9 15:33 issue.txt
-rwxr-xr-x  1 root root 4935528 Sep 25 12:06 kernel7.img
-rwxr-xr-x  1 root root 4685760 Sep 25 12:06 kernel.img
-rwxr-xr-x  1 root root    1494 Mar  9  2018 LICENCE.broadcom
-rwxr-xr-x  1 root root   18974 Oct  9 15:33 LICENSE.oracle
drwxr-xr-x  2 root root    4096 Oct  9 14:50 overlays
-rwxr-xr-x  1 root root  677764 Sep 25 12:06 start_cd.elf
-rwxr-xr-x  1 root root 5108996 Sep 25 12:06 start_db.elf
-rwxr-xr-x  1 root root 2847044 Sep 25 12:06 start.elf
-rwxr-xr-x  1 root root 4047876 Sep 25 12:06 start_x.elf
root@nfs-pi:/home/pi# ls -al /nfs/client1/
total 88
drwxr-xr-x 22 root root 4096 Oct 18 08:32 .
drwxr-xr-x  3 root root 4096 Oct 18 08:32 ..
drwxr-xr-x  2 root root 4096 Oct 18 08:17 bin
drwxr-xr-x  2 root root 4096 Oct 18 08:31 boot
drwxr-xr-x  2 root root 4096 Oct  9 14:47 debootstrap
drwxr-xr-x  2 root root 4096 Oct 18 08:31 dev
drwxr-xr-x 89 root root 4096 Oct 18 10:04 etc
drwxr-xr-x  3 root root 4096 Oct 18 08:23 home
drwxr-xr-x 17 root root 4096 Oct 18 08:17 lib
drwx------  2 root root 4096 Oct  9 15:31 lost+found
drwxr-xr-x  2 root root 4096 Oct  9 14:37 media
drwxr-xr-x  2 root root 4096 Oct  9 14:37 mnt
drwxr-xr-x  4 root root 4096 Oct 18 08:26 opt
dr-xr-xr-x  2 root root 4096 Jan  1  1970 proc
drwx------  6 root root 4096 Oct 18 08:24 root
drwxr-xr-x  2 root root 4096 Oct 18 08:26 run
drwxr-xr-x  2 root root 4096 Oct 18 08:17 sbin
drwxr-xr-x  2 root root 4096 Oct  9 14:37 srv
dr-xr-xr-x  2 root root 4096 Jan  1  1970 sys
drwxrwxrwt 10 root root 4096 Oct 18 08:48 tmp
drwxr-xr-x 11 root root 4096 Oct 18 08:26 usr
drwxr-xr-x 11 root root 4096 Oct  9 15:33 var

This is cmdline.txt

root@nfs-pi:/home/pi# cat /tftpboot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.1.1:/nfs/client1,vers=3 rw ip=dhcp rootwait elevator=deadline

I only manage to get green led 4 blinks.

root@nfs-pi:/home/pi# sudo tcpdump -i eth0 | grep RRQ
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:26.247703 IP 192.168.1.52.49152 > 192.168.1.1.tftp:  21 RRQ "bootcode.bin" octet
14:53:26.298628 IP 192.168.1.52.49152 > 192.168.1.1.tftp:  20 RRQ "bootsig.bin" octet
14:53:28.533045 IP 192.168.1.52.49154 > 192.168.1.1.tftp:  29 RRQ "autoboot.txt" octet tsize 0
14:53:30.583049 IP 192.168.1.52.49155 > 192.168.1.1.tftp:  27 RRQ "config.txt" octet tsize 0
14:53:32.474710 IP 192.168.1.52.49156 > 192.168.1.1.tftp:  29 RRQ "recovery.elf" octet tsize 0
14:53:33.482289 IP 192.168.1.52.49157 > 192.168.1.1.tftp:  26 RRQ "start.elf" octet tsize 0
14:53:34.531525 IP 192.168.1.52.49158 > 192.168.1.1.tftp:  26 RRQ "fixup.dat" octet tsize 0

…Nothing else show after waiting 3 minutes and the client PI (PI 3 B) green led makes 4 blinks.

Next step was to turn on debugging via serial cable (@pelwell advice): sed -ie 's/BOOT_UART=0/BOOT_UART=1/' /tftpboot/bootcode.bin and retry. I also filter the network capture on the Pi's address.

dump.zip

Uart output:

[00][00][00][00][00][00]

Raspberry Pi Bootcode

USB ethernet boot

No response from ARP request

Raspberry Pi Bootcode

Raspberry Pi Bootcode

USB ethernet boot

No response from ARP request

Raspberry Pi Bootcode

TCP

root@nfs-pi:/tftpboot# sudo tcpdump -i eth0 | grep 192.168.1.52.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:32:27.524463 ARP, Request who-has 192.168.1.1 tell 192.168.1.52, length 46
16:32:27.524814 IP 192.168.1.52.49152 > 192.168.1.1.tftp:  21 RRQ "bootcode.bin" octet
16:32:27.525070 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.525523 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.525628 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.526052 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.526142 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.526560 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.526651 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.527066 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.527153 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.527602 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.527708 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.528153 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.528244 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.528660 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.528752 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.529179 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.529275 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.529692 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.529782 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.530216 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.530318 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.530781 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.530875 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.531317 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.531410 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.531826 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.531916 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.532330 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.532418 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.532839 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.532941 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.533370 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.533460 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.533899 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.533989 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.534406 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.534537 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.534952 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.535042 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.535464 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.535564 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.535992 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.536082 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.536553 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.536643 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.537058 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.537153 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.537566 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.537655 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.538077 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.538176 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.538595 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.538687 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.539103 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.539191 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.539621 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.539712 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.540148 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.540242 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.540658 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.540746 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.541156 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.541238 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.541646 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.541727 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.542151 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.542229 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.542644 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.542728 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.543143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.543222 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.543642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.543720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.544143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.544221 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.544645 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.544725 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.545143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.545223 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.545643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.545722 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.546143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.546220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.546643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.546720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.547143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.547218 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.547646 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.547724 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.548142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.548223 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.548642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.548721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.549143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.549219 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.549643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.549721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.550143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.550220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.550642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.550720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.551142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.551218 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.551642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.551721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.552142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.552218 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.552642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.552719 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.553146 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.553223 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.553643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.553723 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.554142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.554221 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.554644 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.554722 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.555142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.555221 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.555642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.555720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.556143 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.556219 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.556643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.556720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.557142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.557220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.557643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.557720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.558142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.558220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.558645 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.558724 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.559146 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.559226 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.559642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.559720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.560142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.560220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.560644 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.560722 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.561141 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.561220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.561642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.561721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.562142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.562220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.562642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.562719 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.563142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.563220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.563642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.563721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.564144 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.564223 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.564645 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.564725 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.565142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.565220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.565641 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.565721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.566141 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.566220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.566641 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.566720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.567142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.567220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.567642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.567719 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.568144 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.568221 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.568642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.568718 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.569142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.569218 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.569645 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.569724 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.570142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.570221 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.570642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.570720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.571142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.571218 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.571642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.571720 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.572142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.572219 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.572642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.572719 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.573142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.573220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.573642 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.573721 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.574145 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.574222 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.574645 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.574723 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.575145 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.575222 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.575643 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.575723 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 516
16:32:27.576142 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.576220 IP 192.168.1.1.46658 > 192.168.1.52.49152: UDP, length 408
16:32:27.576594 IP 192.168.1.52.49152 > 192.168.1.1.46658: UDP, length 4
16:32:27.576596 IP 192.168.1.52.49152 > 192.168.1.1.tftp:  20 RRQ "bootsig.bin" octet
16:32:27.576947 IP 192.168.1.1.36157 > 192.168.1.52.49152: UDP, length 41
16:32:30.491045 IP 192.168.1.52.49154 > 192.168.1.1.tftp:  29 RRQ "autoboot.txt" octet tsize 0
16:32:31.707388 IP 192.168.1.52.49155 > 192.168.1.1.tftp:  27 RRQ "config.txt" octet tsize 0
16:32:32.604506 ARP, Request who-has 192.168.1.52 tell 192.168.1.1, length 28
16:32:32.604869 ARP, Reply 192.168.1.52 is-at b8:27:eb:5a:8e:32 (oui Unknown), length 46
16:32:33.209512 IP 192.168.1.52.49156 > 192.168.1.1.tftp:  29 RRQ "recovery.elf" octet tsize 0
16:32:34.487254 IP 192.168.1.52.49157 > 192.168.1.1.tftp:  26 RRQ "start.elf" octet tsize 0
16:32:35.595173 IP 192.168.1.52.49158 > 192.168.1.1.tftp:  26 RRQ "fixup.dat" octet tsize 0
root@nfs-pi:/tftpboot# tail -F /var/log/daemon.log
Oct 18 16:30:29 nfs-pi dnsmasq-dhcp[795]: 653460281 PXE(eth0) b8:27:eb:5a:8e:32 proxy
Oct 18 16:30:29 nfs-pi dnsmasq-dhcp[795]: 653460281 tags: eth0
Oct 18 16:30:29 nfs-pi dnsmasq-dhcp[795]: 653460281 reply delay: 1
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 broadcast response
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 sent size:  1 option: 53 message-type  2
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 sent size:  4 option: 54 server-identifier  192.168.1.1
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 sent size: 17 option: 97 client-machine-id  00:44:44:44:44:44:44:44:44:44:44:44:44:44...
Oct 18 16:30:30 nfs-pi dnsmasq-dhcp[795]: 653460281 sent size: 32 option: 43 vendor-encap  06:01:03:0a:04:00:50:58:45:09:14:00:00:11...
Oct 18 16:30:30 nfs-pi dnsmasq-tftp[795]: file /tftpboot/bootsig.bin not found
Oct 18 16:30:30 nfs-pi dnsmasq-tftp[795]: sent /tftpboot/bootcode.bin to 192.168.1.52

So, next, I try made a simple separate network just for pxe boot, where PI server will be also DHCP server.

I made a new separate network from one TL-WR541G router (192.168.2.1 on lan interface), one PI PXE Server (192.168.2.254, manual setup and reserved on router DHCP) and one PI PXE Client (192.168.2.11 reserved on router DHCP, also worked with DHCP from router without reservation). I re-done the configuration (to be sure it is as per instructions) for the PI PXE Server as per https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md. I have set the “IP & MAC Binding” in the router for the PI PXE Server (I knew this is necessary if you want wake-on-lan thru a router so I thought it could help the Client arp issue). I have put the router wan on my network, configure as “Dynamic IP” and set the 192.168.2.254 in DMZ zone so I could do ssh on it. Made about 6 power off/reboot cycles on PI PXE Client and all the time it boots successfully.

Here is the boot log:

root@nfs-pi:/home/pi# tail -F /var/log/daemon.log
Oct 19 20:10:38 nfs-pi dnsmasq-dhcp[895]: 653460281 available DHCP subnet: 192.168.2.255/255.255.255.0
Oct 19 20:10:38 nfs-pi dnsmasq-dhcp[895]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001
Oct 19 20:10:38 nfs-pi dnsmasq-dhcp[895]: 653460281 PXE(eth0) b8:27:eb:5a:8e:32 proxy
Oct 19 20:10:38 nfs-pi dnsmasq-dhcp[895]: 653460281 tags: eth0
Oct 19 20:10:38 nfs-pi dnsmasq-dhcp[895]: 653460281 reply delay: 1
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 broadcast response
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 sent size:  1 option: 53 message-type  2
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 sent size:  4 option: 54 server-identifier  192.168.2.254
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 sent size: 17 option: 97 client-machine-id  00:44:44:44:44:44:44:44:44:44:44:44:44:44...
Oct 19 20:10:39 nfs-pi dnsmasq-dhcp[895]: 653460281 sent size: 32 option: 43 vendor-encap  06:01:03:0a:04:00:50:58:45:09:14:00:00:11...
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: file /tftpboot/bootsig.bin not found
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/bootcode.bin to 192.168.2.101
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/autoboot.txt not found
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: error 0 Early terminate received from 192.168.2.101
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: failed sending /tftpboot/5e5a8e32/start.elf to 192.168.2.101
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/config.txt to 192.168.2.101
Oct 19 20:10:40 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery.elf not found
Oct 19 20:10:42 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/start.elf to 192.168.2.101
Oct 19 20:10:42 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/fixup.dat to 192.168.2.101
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery.elf not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/config.txt to 192.168.2.101
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/dt-blob.bin not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery.elf not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/config.txt to 192.168.2.101
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/bootcfg.txt not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/cmdline.txt to 192.168.2.101
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery8.img not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery8-32.img not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery7.img not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/recovery.img not found
Oct 19 20:10:43 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/kernel8.img not found
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/kernel8-32.img not found
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/armstub8.bin not found
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: error 0 Early terminate received from 192.168.2.101
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: failed sending /tftpboot/5e5a8e32/kernel7.img to 192.168.2.101
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/armstub8-32.bin not found
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/armstub7.bin not found
Oct 19 20:10:44 nfs-pi dnsmasq-tftp[895]: file /tftpboot/5e5a8e32/armstub.bin not found
Oct 19 20:10:48 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/kernel7.img to 192.168.2.101
Oct 19 20:10:48 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/bcm2710-rpi-3-b.dtb to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/rpi-ft5406.dtbo to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/rpi-backlight.dtbo to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/config.txt to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/gpio-poweroff.dtbo to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/i2c-rtc.dtbo to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/gpio-fan.dtbo to 192.168.2.101
Oct 19 20:10:49 nfs-pi dnsmasq-tftp[895]: sent /tftpboot/5e5a8e32/overlays/pi3-disable-bt.dtbo to 192.168.2.101
Oct 19 20:10:56 nfs-pi dnsmasq-dhcp[895]: 3427905433 available DHCP subnet: 192.168.2.255/255.255.255.0
Oct 19 20:10:56 nfs-pi dnsmasq-dhcp[895]: 3427905433 available DHCP subnet: 192.168.2.255/255.255.255.0
Oct 19 20:10:56 nfs-pi rpc.mountd[438]: authenticated mount request from 192.168.2.101:739 for /nfs/client1 (/nfs/client1)
Oct 19 20:11:04 nfs-pi dnsmasq-dhcp[895]: 3575090559 available DHCP subnet: 192.168.2.255/255.255.255.0
Oct 19 20:11:04 nfs-pi dnsmasq-dhcp[895]: 3575090559 vendor class: dhcpcd-6.11.5:Linux-4.14.71-v7+:armv7l:BCM2835
Oct 19 20:11:04 nfs-pi dnsmasq-dhcp[895]: 3575090559 client provides name: pxe-pi-clone01

Now It is working fine on this dedicated network.

Paul

unix0r commented 6 years ago

The new Raspberry Pi 3b+ handles PXE like a charm.

Tested with isc-dhcp and dnsmasq. Closed.

Flole998 commented 5 years ago

@unix0r Unfortunately it doesn't. I am using isc-dhcp and the Raspberry never acknowledges the DHCP Offer (this is not okay in the first place). To make things worse, it only requests the bootcode.bin and bootcode.sig, then it sends an ARP Request to get the IP of the TFTP Server (which is on a different subnet, so this is another violation of the IP Standard) but never get's a reply. In this case it should ask the default Gateway as that knows how to route the request but that never happens, instead aa:aa.... is the receiver (another violation of the standard).

This is just completely broken. I suggest to actually read the standard and then follow it, there is a reason it's the worldwide standard and by violating it you are breaking lot's of stuff! I really hope this can be fixed in the bootcode.bin, otherwise this is a huge issue.

ghollingworth commented 5 years ago

Since most of the code you are describing is in the bootrom then no it can't be fixed in bootcode.bin but many other people have got this working fine. I would suggest using a fixed DHCP range for your Raspberry Pis and serve those using dnsmasq, this would enable you to reproduce the way the code was developed and will give you a better option.

Either that or use PiServer to set up a server on an x86 or Raspberry Pi.

Flole998 commented 5 years ago

It is impossible that this will work through a Router because the raspberry is simply ignoring the default gateway (as I described before). But if this is really part of the bootrom (there was a slight chance as the bootcode.bin was loaded at that point in time) then you're really out of luck here.

Also after a kernel panic it gets stuck after serialnumer/start.elf is supposed to be loaded, no matter of that's successful or not.

This code is broken really bad and if this can't be fixed, there are quite a few devices that we have to return. I will talk to our sales representative on Monday about that. And to be honest I'm not even feeling sorry if such a bad code gets punished with quite a few returned devices (and the cost associated with that).

ghollingworth commented 5 years ago

That's probably for the best, the router problem was fixed with the 3B+

Flole998 commented 5 years ago

I am testing on a 3B+....

ghollingworth commented 5 years ago

Well if the gateway is advertised in the DHCP reply then it should use it... Obviously it'll still do an ARP for the gateway itself but shouldn't ARP for the TFTP server, just go through the gateway.

In the end Mythic Beasts who run a few hundred Pi 3s on an isc-dhcp setup have no issues except with failed packets which occasionally means a Pi won't start up. In this situation they monitor the Pi and if it doesn't start they power it off and back on again (using a PoE managed switch to control the power).

If you can't get this working you could instead using an SD card containing only the bootcode.bin file. It would then be possible to apply fixes to the bootcode.bin file (and output UART debug so we can see what is happening).

Once booted you can then disable the SD card peripheral to stop it from being accessed by the user (to avoid it ever getting corrupted)

Flole998 commented 5 years ago

I just double-checked to make sure that it is inded a pi3b+ that I am testing with.

At first it works perfectly fine for the bootcode.bin and bootcode.sig (might have gotten that name wrong), it's using the gateway there and absolutely no issues, but for the next file it is not working correctly (after loading the bootcode.bin the ARP Request for the TFTP Server is beeing sent). Thats why I thought that the loading of that file might already be part of the bootcode.bin and so that it could get fixed even without a costly replacement. I got around that by giving the gateway an alias on the Raspberry Side so it responds with it's MAC to that request, but this is just really bad and I would not consider this a fix at all.

I do not have any issues with missed packets at all.

In addition to all that, after the device has been reset by the watchdog, it gets stuck after trying to load the serialnumer/start.elf which is an even bigger problem as this means all the devices will get stuck if the NFS Server goes down (or the connections are interrupted). Definitely not practical to start walking around and reset all of the devices.

I tried to use SD Cards at first, but right now I have 2 of my 10 Test-Cards on my desk that are no longer working at all, even though they just contained the bootloader and kernel. They behave like a piece of plastic, not being recognized at all anymore.

In case this helps:

# sha1sum /boot/bootcode.bin
cedaeb8daa7728e9857d199b4f03d84936499b7f  /boot/bootcode.bin
# /opt/vc/bin/vcgencmd version
Nov  4 2018 16:31:07
Copyright (c) 2012 Broadcom
version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)
ghollingworth commented 5 years ago

Well in that case we can do something about it... So first we could probably just trying sorting out the problem with the ARP request.

I'd suggest first of all connecting a UART serial debug to the Pi using GPIO13,14 on pins 8 and 10 of the GPIO connector. https://pinout.xyz/pinout/uart

Then do the magic to bootcode.bin to enable early UART output

sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin

Keep a backup of the original file just in case. It should output at 115200-8-n-1

Then post the UART log and we'll see what you get

Flole998 commented 5 years ago

Alright, so the first thing I have done is simply removed my ARP Hack so that it ARP-Requests an IP that is not on that subnet. The log is very simple for that:

<\r>Raspberry Pi Bootcode<\n><\r><\n> <\r>USB ethernet boot<\n><\r>No response from ARP request<\n><\r><\n>

Now talking about the issue after a watchdog reset: I added my Workaround again and then let it boot, then I started the logging and made the watchdog trigger:

<\r>Raspberry Pi Bootcode<\n><\r><\n> <\r>USB ethernet boot<\n><\r>Done ARP for x.x.x.x got 10:21:19:02:88:98<\n><\r><\n> <\r><\n> <\r><\n> <\r><\n> <\r>Raspberry Pi Bootcode<\n><\r>

and now it's stuck there, last file requested was myserial/start.elf

pelwell commented 5 years ago

Two (probably) related issues for comparison: https://github.com/raspberrypi/firmware/issues/937 and https://github.com/raspberrypi/firmware/issues/975

Flole998 commented 5 years ago

The first issue doesn't seem to be related, in that one it doesn't seem to work even when the TFTP Server is on the same Subnet. The second one is also not related, my DHCP Discover works perfectly fine, the bootcode.bin is being requested and delivered, which is why we are (thankfully) talking about an issue here that can be fixed in software.

fedorovvl commented 5 years ago

if it help someone.. we use about 400 rpi3 with pxe+nfsroot for a 1 year in production with following scheme: 6 subnets on tftp/dhcp server with AA:AA:AA:AA:AA:AA mac on each interface

eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.10  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a8aa:aaff:feaa:aaaa  prefixlen 64  scopeid 0x20<link>
        ether aa:aa:aa:aa:aa:aa  txqueuelen 1000  (Ethernet)
        RX packets 6619806  bytes 499133814 (476.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 66137  bytes 2779178 (2.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth0.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.10  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a8aa:aaff:feaa:aaaa  prefixlen 64  scopeid 0x20<link>
        ether aa:aa:aa:aa:aa:aa  txqueuelen 1000  (Ethernet)
        RX packets 6619806  bytes 499133814 (476.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 66137  bytes 2779178 (2.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
.......

6 subnet declaration on dhcp server

subnet 192.168.1.0 netmask 255.255.255.0 {
    option routers 192.168.1.1;
    option option-43 "192.168.1.10";
    option tftp-server-name "192.168.1.10";
    next-server 192.168.1.10;
    option root-path "192.168.1.10:/opt/nfsroot,vers=3";
    pool {
        range 192.168.1.11 192.168.1.250;
    }
}
subnet 192.168.2.0 netmask 255.255.255.0 {
    option routers 192.168.2.1;
    option option-43 "192.168.2.10";
    option tftp-server-name "192.168.2.10";
    next-server 192.168.2.10;
    option root-path "192.168.2.10:/opt/nfsroot,vers=3";
    pool {
        range 192.168.2.11 192.168.2.250;
    }
}

same for exports

/opt/nfsroot 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
/opt/nfsroot 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash)

cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs rw ip=dhcp rootwait elevator=deadline

and finally! we use bootcode from comment above, coz it use AA mac when ARP fail 10/10 success boot

Flole998 commented 5 years ago

The "default" bootcode uses the aa:... MAC aswell, but seriously, that aa:... thing is just extremely bad. A MAC is also supposed to be unique....

If you get the chance, could you please try to cause a kernel panic on one of them and wait for it to reboot and see if it get's past requesting *serialnumber/start.elf? That's an issue I am experiencing even with the aa;... mac set

fedorovvl commented 5 years ago

my pi successfully booted after panic.. here is a log

Nov 27 08:03:52 bootserver dhcpd: DHCPDISCOVER from b8:27:eb:xx:xx:xx via ens160
Nov 27 08:03:53 bootserver dhcpd: DHCPOFFER on 192.168.1.63 to b8:27:eb:xx:xx:xx via ens160
Nov 27 08:03:53 bootserver in.tftpd[3947]: Client ::ffff:192.168.1.63 finished bootcode.bin
Nov 27 08:03:53 bootserver in.tftpd[3951]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:03:55 bootserver in.tftpd[3953]: Client ::ffff:192.168.1.63 finished start.elf
Nov 27 08:03:55 bootserver in.tftpd[3954]: Client ::ffff:192.168.1.63 finished fixup.dat
Nov 27 08:03:55 bootserver in.tftpd[3956]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:03:55 bootserver in.tftpd[3959]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:03:56 bootserver in.tftpd[3961]: Client ::ffff:192.168.1.63 finished cmdline.txt
Nov 27 08:04:00 bootserver in.tftpd[3967]: Client ::ffff:192.168.1.63 finished kernel8.img
Nov 27 08:04:00 bootserver in.tftpd[3968]: Client ::ffff:192.168.1.63 finished bcm2710-rpi-3-b.dtb
Nov 27 08:04:00 bootserver in.tftpd[3969]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:04:00 bootserver in.tftpd[3970]: Client ::ffff:192.168.1.63 finished overlays/w1-gpio.dtbo
Nov 27 08:04:00 bootserver in.tftpd[3971]: Client ::ffff:192.168.1.63 finished overlays/pi3-disable-wifi.dtbo
Nov 27 08:04:00 bootserver in.tftpd[3972]: Client ::ffff:192.168.1.63 finished overlays/vc4-fkms-v3d.dtbo
Nov 27 08:04:12 bootserver dhcpd: DHCPDISCOVER from b8:27:eb:xx:xx:xx via ens160
Nov 27 08:04:12 bootserver dhcpd: DHCPOFFER on 192.168.1.63 to b8:27:eb:xx:xx:xx via ens160
Nov 27 08:04:12 bootserver dhcpd: DHCPREQUEST for 192.168.1.63 (192.168.1.2) from b8:27:eb:xx:xx:xx via ens160
Nov 27 08:04:12 bootserver dhcpd: DHCPACK on 192.168.1.63 to b8:27:eb:xx:xx:xx via ens160
Nov 27 08:04:12 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported
Nov 27 08:04:17 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported
Nov 27 08:04:27 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported
Nov 27 08:04:48 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported
Nov 27 08:05:18 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported
Nov 27 08:05:48 bootserver rpc.mountd[1029]: refused mount request from 192.168.1.63 for /opt/fakenfs (/): not exported

!panic!

Nov 27 08:06:18 bootserver dhcpd: DHCPDISCOVER from b8:27:eb:xx:xx:xx via ens160
Nov 27 08:06:19 bootserver dhcpd: DHCPOFFER on 192.168.1.63 to b8:27:eb:xx:xx:xx via ens160
Nov 27 08:06:19 bootserver in.tftpd[4081]: Client ::ffff:192.168.1.63 finished bootcode.bin
Nov 27 08:06:19 bootserver in.tftpd[4085]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:06:21 bootserver in.tftpd[4087]: Client ::ffff:192.168.1.63 finished start.elf
Nov 27 08:06:21 bootserver in.tftpd[4088]: Client ::ffff:192.168.1.63 finished fixup.dat
Nov 27 08:06:22 bootserver in.tftpd[4090]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:06:22 bootserver in.tftpd[4093]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:06:22 bootserver in.tftpd[4095]: Client ::ffff:192.168.1.63 finished cmdline.txt
Nov 27 08:06:26 bootserver in.tftpd[4101]: Client ::ffff:192.168.1.63 finished kernel8.img
Nov 27 08:06:26 bootserver in.tftpd[4102]: Client ::ffff:192.168.1.63 finished bcm2710-rpi-3-b.dtb
Nov 27 08:06:26 bootserver in.tftpd[4103]: Client ::ffff:192.168.1.63 finished config.txt
Nov 27 08:06:26 bootserver in.tftpd[4104]: Client ::ffff:192.168.1.63 finished overlays/w1-gpio.dtbo
Nov 27 08:06:26 bootserver in.tftpd[4105]: Client ::ffff:192.168.1.63 finished overlays/pi3-disable-wifi.dtbo
Nov 27 08:06:26 bootserver in.tftpd[4106]: Client ::ffff:192.168.1.63 finished overlays/vc4-fkms-v3d.dtbo
Flole998 commented 5 years ago

That does indeed look perfectly fine. I will do a Wireshark capture again tomorrow to see what's going on here in this case. I'm causing the panic by writing "c" to sysrq and I have the watchdog enabled, just in case that matters. Could you please also post the checksum of the bootcode.bin, just to be sure. If i remember correctly there was no request to config.txt before the serialnumber/start.elf.

fedorovvl commented 5 years ago

sure..

# md5sum bootcode.bin
4bad2380f49635c56bbacdad6262355b  bootcode.bin
# sha256sum bootcode.bin
5b3297576f984aa2f45d32bee39ef857ac0676052c1bcfc090b6aab16f827791  bootcode.bin
# sha512sum bootcode.bin
51491f356252bf5b8deec5a612d3e922dd00056fd293358ce451d0295a68c0f8e370b94b96a095bf1e823ad9dfc4e24f37bd4ca684f07fcdad1d823feb761339  bootcode.bin
Flole998 commented 5 years ago

The issue I am having is also in #1078 and in there a few other issues are mentioned aswell. The bootcode.bin needs to be updated to include a fix for that, it's ridiculous that the bootrom (which is harder to update) is doing this correctly and the bootcode.bin which can be updated easily is still broken!