[U-Boot] Booting from network

[U.Mutlu <for-gmane@mutluit.com>]

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.