tftpboot: efi_load_pe: Invalid DOS Signature
#1
Hi all, I'm looking for help with tftp boot from SPI flash.
Booting from flash works fine, the rock boards load their pxelinux.0 from tftp. Then for some reason the bootloader seems to ignore my 'fdt /dtb' entry and requests /dtb/rockchip/rk3328-rock64.dtb.

After successfully loading this file it throws the following error:

Filename 'dtb/rockchip/rk3328-rock64.dtb'.
Load address: 0x1f00000
Loading: ####
         1.8 MiB/s
done
Bytes transferred = 56922 (de5a hex)
## Starting EFI application at 02000000 ...
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 9223372036854775806

Can someone provide any insight on why this happens and how to fix it?

Thanks!

For the sake of completeness here's my pxelinux.0:
default rock64-kernel-4.4
prompt 0
timeout 3

menu title Boot options

label rock64-kernel-4.4
   kernel /Image
   initrd /initrd.img
   fdt /dtb
   append earlycon=uart8250,mmio32,0xff130000 rw root=/dev/nfs nfsroot=${serverip}:/data/rootfs/rock64-1 rootwait init=/sbin/init mtdparts=spi32766.0:32k(system),4064k(loader),3840k(reserved),256k(vendor),4M(uboot),4M(atf)
  Reply
#2
(05-17-2018, 11:24 AM)wirr Wrote: ## Starting EFI application at 02000000 ...
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 9223372036854775806

It sounds like there is something wrong with the initial pxe boot stuff... maybe it's grabbing the pxelinux.0 file and it shouldn't be, since it can't run dos executables? (clutching at straws here).

I have currently broken my pxe boot stuff, as I was testing something out, and haven't bothered fixing it back up, else I'd be able to copy in my config.

I did document how I had the menu set up and where some of the files came from, but not the full setup. But I basically cobbled something together from these two articles...

https://manski.net/2016/09/pxe-server-on...on-ubuntu/

http://www.vandewerken.com.au/blog/linux...1-memtest/
  Reply
#3
(05-18-2018, 03:41 AM)pfeerick Wrote:
(05-17-2018, 11:24 AM)wirr Wrote: ## Starting EFI application at 02000000 ...
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 9223372036854775806

It sounds like there is something wrong with the initial pxe boot stuff... maybe it's grabbing the pxelinux.0 file and it shouldn't be, since it can't run dos executables? (clutching at straws here).

I have currently broken my pxe boot stuff, as I was testing something out, and haven't bothered fixing it back up, else I'd be able to copy in my config.

I did document how I had the menu set up and where some of the files came from, but not the full setup. But I basically cobbled something together from these two articles...

https://manski.net/2016/09/pxe-server-on...on-ubuntu/

http://www.vandewerken.com.au/blog/linux...1-memtest/

thanks pfeerick for your thoughts. yes, there was something wrong with the initial pxe boot stuff, I now at least get the boot menu to load. Still I have not yet managed to successfully boot from tftp. So I'd be very interested in the layout of your tftp root tree as well as your dhcp config. What value are you using for the bootfile parameter? Is it correct that u-boot does not require any binaries from the pxelinux package to be made available on the tftp server?
  Reply
#4
(05-21-2018, 02:34 PM)wirr Wrote: thanks pfeerick for your thoughts. yes, there was something wrong with the initial pxe boot stuff, I now at least get the boot menu to load. Still I have not yet managed to successfully boot from tftp. So I'd be very interested in the layout of your tftp root tree as well as your dhcp config. What value are you using for the bootfile parameter? Is it correct that u-boot does not require any binaries from the pxelinux package to be made available on the tftp server?

That I can't tell you. I installed some other PXE boot system with the intention of going that way, and in the process wiped out the config I had working with the rock64. But I suspect you are correct... that it doesn't need the binaries, as it gets what it needs from the pxeconfig menu file, and pulls down the kernel and initrd images as instructed by said menu file.

I didn't change the default settings, which may or may not have been part of the reason I couldn't get the bugger to pxe boot without manually setting the server ip, but it booted fine after I did that and told it to continue. I'll try and come back to getting it working early next week.
  Reply
#5
(05-22-2018, 05:22 AM)pfeerick Wrote: That I can't tell you. I installed some other PXE boot system with the intention of going that way, and in the process wiped out the config I had working with the rock64. But I suspect you are correct... that it doesn't need the binaries, as it gets what it needs from the pxeconfig menu file, and pulls down the kernel and initrd images as instructed by said menu file.

I didn't change the default settings, which may or may not have been part of the reason I couldn't get the bugger to pxe boot without manually setting the server ip, but it booted fine after I did that and told it to continue. I'll try and come back to getting it working early next week.

I've almost figured it out. Trying to document it here, so it may be of use to someone else:

Note: In opposite to bootstrapping from a NICs PXE boot environment, there is no need to provide a bootloader (eg. pxelinux) over tftp. u-boot is capable of directly loading a Linux kernel image from tftp.

1. dnsmasq configuration
- The dhcp-boot option instructs dnsmasq to include a bootfile and tftp server option in the DHCP offer. Note: The bootfile is mandatory, if it's not specified dnsmasq will also omit the tftp server option.
- If it gets no bootfile option the rock64 will always request a specific file name from tftp (for example C0A80AC9.img) and will stay in an infinite boot loop
So I've specified the following option to dnsmasq which will cause it to deliver the tftp server address along with the unfortunately necessary dummy bootfile:
Code:
dhcp-boot=dummy,netserv,<tftp server IP>


2. Boot config
The following boot config at <tftp root>/pxelinux.cfg/default-arm (one of several hardcoded defaults which are requested by u-boot) allowed me to boot the selected kernel and initrd images without manual user intervention:
Code:
label Linux-aarch64
   kernel /Image
   initrd /initrd.img
   devicetreedir /dtbs
   append earlycon=uart8250,mmio32,0xff130000 printk.devkmsg=on panic=10 coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} hostname=${board}-${serial#} ip=::::${board}-${serial#}::: root=/dev/nfs rw nfsroot=${serverip}:/mnt/rootfs,rsize=32768,wsize=32768 cloud-init=disabled mtdparts=spi32766.0:32k(system),4064k(loader),3840k(reserved),256k(vendor),4M(uboot),4M(atf)
I took some inspiration from ayufans github repository at https://github.com/ayufan-rock64/cluster-build but had to modify the console options to be able to still get console output after loading the kernel.

3. tftp root directory
Matching the above boot config I'm using the following tftp root:
Code:
├── dtbs
│   ├── rockchip
│   │   ├── rk3328-evb.dtb
│   │   ├── rk3328-rock64.dtb
├── Image
├── initrd.img
└── pxelinux.cfg
   └── default-arm

4. Choice of kernel
Interestingly I've had no success in booting the kernel and initrd image from linux-image-4.4.77-rockchip-ayufan-136, which I use to boot from eMMC. The kernel crashed with the following error:


Code:
[    1.209418] usbcore: registered new interface driver rndis_host
[    1.210616] rockchip-dwc3 usb@ff600000: could not get reset controller
[    1.211287] rockchip-dwc3: probe of usb@ff600000 failed with error -22
[    1.213457] Unable to handle kernel NULL pointer dereference at virtual address 00000031
[    1.214222] pgd = ffffff80092fd000
[    1.214543] [00000031] *pgd=00000000feffe003, *pud=00000000feffe003, *pmd=0000000000000000
[    1.215332] Internal error: Oops: 96000005 [#1] SMP
[    1.215785] Modules linked in:
[    1.216088] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.77-rockchip-ayufan-136 #1
[    1.216795] Hardware name: Pine64 Rock64 (DT)
[    1.217203] task: ffffffc0f5d40000 ti: ffffffc0f5d48000 task.ti: ffffffc0f5d48000
[    1.217906] PC is at do_raw_spin_lock+0x20/0x158
[    1.218341] LR is at _raw_spin_lock_irqsave+0x28/0x38
[    1.218808] pc : [<ffffff8008105014>] lr : [<ffffff8008b93198>] pstate: 600001c5
[    1.219489] sp : ffffffc0f5d4bb40
[    1.219802] x29: ffffffc0f5d4bb40 x28: 0000000000000000
[    1.220302] x27: ffffff800909ba60 x26: ffffff800900dd28
[    1.220802] x25: ffffffc0fefb4b90 x24: ffffffc0fefb4790
[    1.221302] x23: 0000000000000003 x22: ffffffc0f43b8b40
[    1.221803] x21: ffffffc0f5f63c10 x20: 000000000000002d        

OTOH mainline kernel 4.16 with initrd from linux-image-4.16.0-rockchip-ayufan-213-g027e722bb boots just fine. This kernel unfortunately is not capable of properly initializing the installed eMMC card.

5. NFS root
To get a usable root file system I've simply called 'debootstrap' to provide a debian base image (I am running tftp and NFS on the same rock64 board therefore I don't have to explicitly specify the CPU architecture).
Code:
deboostrap stretch /mnt/rootfs

My /etc/exports for 'nfs-kernel-server'
Code:
/mnt/        <IP Subnet/CIDR>(rw,sync,no_root_squash,no_subtree_check)


6. Open issues
a) Frequent timeouts and UDP checksum errors
When I try to boot from tftp, 9 out of 10 times u-boot reports so many UDP checksum errors that the process aborts. The device doesn't retry to bootstrap and has to be manually restarted, to the point where the network boot feature practically is unusable. Could this be an issue in u-boots network drivers? I've installed u-boot in flash using the scripts from ayufans 0.6.41 release.

b) Rockchip linux kernel crashes if started from the tftp
This does not make any sense to me as this kernel (4.4.77-rockchip-ayufan-136) boots without any problem if directly loaded from eMMC (w/o u-boot). Any ideas?
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)