Chris Packham wrote on 04/07/2019 01:22 AM:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, <for-gm...@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.



_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to