[U-Boot] Booting from network

[U-Boot] Booting from network

[U.Mutlu]

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

-- 
U.Mutlu

[U-Boot] Booting from network

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

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.

[U-Boot] Booting from network

[Simon Goldschmidt]

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

[U-Boot] Booting from network

[Matthias Brugger]

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

[U-Boot] Booting from network

[U.Mutlu]

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