[U-Boot] Booting from network

[Matthias Brugger <mbrugger@suse.com>]

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