From mboxrd@z Thu Jan 1 00:00:00 1970 From: U.Mutlu Date: Sun, 7 Apr 2019 18:59:14 +0200 Subject: [U-Boot] Booting from network In-Reply-To: References: Message-ID: <5CAA2C62.5080508@mutluit.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Chris Packham wrote on 04/07/2019 01:22 AM: > 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. > > 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.