From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Brugger Date: Tue, 16 Apr 2019 12:10:16 +0200 Subject: [U-Boot] Booting from network In-Reply-To: <4b000239-99ce-a91b-427e-7b0ee3076699@gmail.com> References: <4b000239-99ce-a91b-427e-7b0ee3076699@gmail.com> Message-ID: <03c7b5c3-57bb-0ddb-7883-b423a9d8c700@suse.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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, 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 at lists.denx.de >> https://lists.denx.de/listinfo/u-boot >> > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot