[U-Boot] Booting from network
I'm booting over the network (GbE) from a tftp server. It works, but is IMHO very slow. Is there a faster method for booting over the net?
boot.cmd: dhcp 0x49000000 tftpboot 0x46000000 192.168.1.201:uImage tftpboot 0x49000000 192.168.1.201:u-boot.dtb setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10 rootfstype=ext4 rw ${extra} bootm 0x46000000 - 0x49000000
Btw, in the above script, can I safely replace the addresses with ${kloadaddr} and ${fdtaddr} ? I wonder where these variables get set or obtained from. (I saw these variables somewhere on the net, but there was no initialisation, so I assumed it must be something internal/intrinsic, right?)
And: though my board can output via HDMI, I've no monitor attached, and a serial cable (TTY to USB) I don't have at the moment. Is there another method to get the u-boot output (or log) to be sent to a remote host/log?
Thx
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, for-gmane@mutluit.com wrote:
I'm booting over the network (GbE) from a tftp server. It works, but is IMHO very slow. Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
Because TFTP sends a block at a time waiting for an ack between blocks it's not going to be as fast as something that runs over TCP and benefits from buffering.
One tunable you might get some use out of is $tftpblocksize, this will increase the number of bytes per block. Try setting this to around 1400 keeping the overall Ethernet frame under 1518.
boot.cmd:
dhcp 0x49000000 tftpboot 0x46000000 192.168.1.201:uImage tftpboot 0x49000000 192.168.1.201:u-boot.dtb setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10 rootfstype=ext4 rw ${extra} bootm 0x46000000 - 0x49000000
Btw, in the above script, can I safely replace the addresses with ${kloadaddr} and ${fdtaddr} ? I wonder where these variables get set or obtained from. (I saw these variables somewhere on the net, but there was no initialisation, so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize. The latter two are set after a successful load. However plenty of boards have $fdtaddr etc in their default environment so you might have acces to those depending on your board.
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment. Is there another method to get the u-boot output (or log) to be sent to a remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its only good for output.
I'd still recommend getting a serial cable if your going to be playing with u-boot becasue at some point you'll do something that stops your board from booting.
Am 07.04.2019 um 01:22 schrieb Chris Packham:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, for-gmane@mutluit.com wrote:
I'm booting over the network (GbE) from a tftp server. It works, but is IMHO very slow. Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
There were some patches for wget on the list (implementing TCP, HTTP and wget command), but I don't think they were in a state to be accepted, so yes, TFTP is pretty much the only option here.
Because TFTP sends a block at a time waiting for an ack between blocks it's not going to be as fast as something that runs over TCP and benefits from buffering.
Depending on what stability you need: I saw some TFTP servers (the one included in www.dhcpserver.de, for example) in the past that sent out some packets in advance (before waiting for the client's ACK). That improves speed pretty well, but the downside is that retransmission handling is pretty much broken. For my purposes (no transmission problems on the local net), this is still a good enough solution to get higher transmission speed. I wouldn't want to use this in a production setup though...
Regards, Simon
One tunable you might get some use out of is $tftpblocksize, this will increase the number of bytes per block. Try setting this to around 1400 keeping the overall Ethernet frame under 1518.
boot.cmd:
dhcp 0x49000000 tftpboot 0x46000000 192.168.1.201:uImage tftpboot 0x49000000 192.168.1.201:u-boot.dtb setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10 rootfstype=ext4 rw ${extra} bootm 0x46000000 - 0x49000000
Btw, in the above script, can I safely replace the addresses with ${kloadaddr} and ${fdtaddr} ? I wonder where these variables get set or obtained from. (I saw these variables somewhere on the net, but there was no initialisation, so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize. The latter two are set after a successful load. However plenty of boards have $fdtaddr etc in their default environment so you might have acces to those depending on your board.
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment. Is there another method to get the u-boot output (or log) to be sent to a remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its only good for output.
I'd still recommend getting a serial cable if your going to be playing with u-boot becasue at some point you'll do something that stops your board from booting. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 07/04/2019 10:51, Simon Goldschmidt wrote:
Am 07.04.2019 um 01:22 schrieb Chris Packham:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, for-gmane@mutluit.com wrote:
I'm booting over the network (GbE) from a tftp server. It works, but is IMHO very slow. Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
There were some patches for wget on the list (implementing TCP, HTTP and wget command), but I don't think they were in a state to be accepted, so yes, TFTP is pretty much the only option here.
Many years ago I used NFS to boot kernel + dtb. Not sure if that will be faster, but it is an alternative :)
Regards, Matthias
Because TFTP sends a block at a time waiting for an ack between blocks it's not going to be as fast as something that runs over TCP and benefits from buffering.
Depending on what stability you need: I saw some TFTP servers (the one included in www.dhcpserver.de, for example) in the past that sent out some packets in advance (before waiting for the client's ACK). That improves speed pretty well, but the downside is that retransmission handling is pretty much broken. For my purposes (no transmission problems on the local net), this is still a good enough solution to get higher transmission speed. I wouldn't want to use this in a production setup though...
Regards, Simon
One tunable you might get some use out of is $tftpblocksize, this will increase the number of bytes per block. Try setting this to around 1400 keeping the overall Ethernet frame under 1518.
boot.cmd:
dhcp 0x49000000 tftpboot 0x46000000 192.168.1.201:uImage tftpboot 0x49000000 192.168.1.201:u-boot.dtb setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10 rootfstype=ext4 rw ${extra} bootm 0x46000000 - 0x49000000
Btw, in the above script, can I safely replace the addresses with ${kloadaddr} and ${fdtaddr} ? I wonder where these variables get set or obtained from. (I saw these variables somewhere on the net, but there was no initialisation, so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize. The latter two are set after a successful load. However plenty of boards have $fdtaddr etc in their default environment so you might have acces to those depending on your board.
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment. Is there another method to get the u-boot output (or log) to be sent to a remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its only good for output.
I'd still recommend getting a serial cable if your going to be playing with u-boot becasue at some point you'll do something that stops your board from booting. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Chris Packham wrote on 04/07/2019 01:22 AM:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, for-gmane@mutluit.com wrote:
I'm booting over the network (GbE) from a tftp server. It works, but is IMHO very slow. Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
Because TFTP sends a block at a time waiting for an ack between blocks it's not going to be as fast as something that runs over TCP and benefits from buffering.
One tunable you might get some use out of is $tftpblocksize, this will increase the number of bytes per block. Try setting this to around 1400 keeping the overall Ethernet frame under 1518.
After attaching a monitor to the device, I now can see that the cause is that sometimes the tftboot (or tftp) command fails, but the script continues... Ie. there is missing some evaluation/test of the return code of the command. One better should do it in a loop with n retries. I've yet to read in u-boot documentation on how one can do such tests in the script.
boot.cmd:
dhcp 0x49000000 tftpboot 0x46000000 192.168.1.201:uImage tftpboot 0x49000000 192.168.1.201:u-boot.dtb setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10 rootfstype=ext4 rw ${extra} bootm 0x46000000 - 0x49000000
Btw, in the above script, can I safely replace the addresses with ${kloadaddr} and ${fdtaddr} ? I wonder where these variables get set or obtained from. (I saw these variables somewhere on the net, but there was no initialisation, so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize. The latter two are set after a successful load. However plenty of boards have $fdtaddr etc in their default environment so you might have acces to those depending on your board.
I now see that the u-boot commands "bdinfo" and "printenv" do print such infos. I haven't grasped yet if that info is persistent, or initialized each time by u-boot, but it seems there could be some persistent store beyond uSD on the device. My device is Banana Pi R1 (aka BPi-R1 or Lamobo R1). I'm relatively new to this board, and also generally to these Raspi-like small devices.
It's IMO a nice PC-like dual-core ARMv7-A20 1GHz 32bit board with GbE router & switch capabilities, but I have one major problem with this board: the SSD (SATA2 3Gbps AHCI) write-speed is only about 52 MB/s (read-speed is about 200 MB/s). I try to find out which component is responsible for the slow write-speed: is it the SATA driver (ahci-sunxi[1c18000.sata]), or other components (HW or SW)? How could one best encircle/pinpoint this SATA specific problem-source?
root@r1-3:/tmp# dmesg | grep -i "sata|ahci" [ 5.485336] ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.11 [ 5.592431] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 5.599953] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled [ 5.607139] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [ 5.616118] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc [ 5.625664] scsi host0: ahci-sunxi [ 5.629551] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 37 [ 5.963890] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
root@r1-3:/tmp# cat /proc/interrupts CPU0 CPU1 ... 37: 3330 2813 GICv2 88 Level ahci-sunxi[1c18000.sata] ...
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment. Is there another method to get the u-boot output (or log) to be sent to a remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its only good for output.
I'd still recommend getting a serial cable if your going to be playing with u-boot becasue at some point you'll do something that stops your board from booting.
Yes, I've already ordered such an adapter cable, will get it tomorrow or tuesday.
participants (4)
-
Chris Packham -
Matthias Brugger -
Simon Goldschmidt -
U.Mutlu