Linux/TMDSICE3359: TFTP boot

Hello,

I'm going to try to set this up on the bench tomorrow. If you can, a wireshark capture between the host/target would go a long way to determine where the ARP is getting lost.

Thanks.

Hi Ron,

Thanks for your message.

I have no previous experience with Wireshark. Nevertheless, I have installed it successfully and could open the dumpcap - I think that is what it is called - page and the corresponding user interface. I have to read up more on setting up the filters. 

I was transferring files using TFTP between my Linux host and another Windows computer running tftpd64 application. I could see the files going across from one PC to the other on TFTP but I could not catch the packets on Wireshark. It is probably a user problem.

Now back to the boot script that I have been using. 

The U-boot bootcmd  will execute a sequence of commands when I boot from the SD card. The bootcmd goes like this when you do a => printenv bootcmd from the U-boot => prompt;

bootcmd=if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt;  run init_console; run envboot; run distro_bootcmd

So, the first problem that I see with the script I sent you yesterday is that it does not execute "run findftd;" to determine the correct image and device tree files in /tftpboot directory of the host. But I know there are more problems there. 

I am trying to break down the "standard" bootcmd mentioned above to see how I can exchange it with a procedure to get tftp going. So, it will be most helpful if you can tell me the following;

a) I would like to skip the first if statement in the bootcmd. I don't see that it does anything for us. This the part where the bootcmd starts and goes with "if test ${boot_fit} -eq 1; then run update_to_;fit; This part doesn't seem to get executed because printenv boot_fit returns boot_fit=0. So, I would like to omit this test. Please comment on why if this is necessary to keep.

b) I would like to start the bootcmd with "run findfdt;" Please confirm if my guess is correct.

c) I would also like to  maintain run "init_console;" because this seems to be working fine and setting up the console through minicom.

d) => printenv envboot returns "envboot= mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev}; if run loadbootscript; then run bootscript; else if run loadbootenv; then echo loaded env from ${bootenvfile}; run import bootenv; fi; if test -n $uenvcmd; then echo Running uenvcmd ...; run uenvcmd; fi; fi; fi;

Most of the boot commands in (d) above are about booting from mmc, however, I am not fully clear about how they relate to eachother. It would be nice if there was a document that broke this down. I am not sure if I can skip this step in writing my own bootcmd. I can see that "bootenvfile" is the same as the uEnv.txt file of U-boot, but I think I need some more clarification is required.

e) It appears "run distro_bootcmd;" runs some variant of the bootcmd based on the media that we are going to boot from. 

All in all, I will appreciate if you can confirm that this is how U-boot is configured and refer me to a document that provides some examples. Also, if there are ways in which the U-boot command structure can be tweaked to allow booting from TFTP, I will appreciate it if you can let me know.

Thanks & Best Regards

 

Hello,

Rather than answer each of your specific questions above at this time, I wanted to get you up and running. Here is a list of commands that I just ran to TFTP Boot an ICE board over CPSW Ethernet. I used the below h/w setup. Please not which connector I'm using and the highlighted jumpers as these are needed to get Ethernet communication going.

I hope the picture is clear. 

Here is a log of the commands that I ran to get the board booted. Please try this on your set up and let's at least get to the same point. Then, if you have specific questions about how this works, I'll be glad to address them. I've left the responses in so you can compare them to what you are seeing.

=> pr bootcmd
bootcmd=if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run en
vboot; run distro_bootcmd
=> pr init_console
init_console=if test $board_name = A335_ICE; then setenv console ttyO3,115200n8;else setenv console
ttyO0,115200n8;fi;
=> setenv ethact cpsw
=> setenv serverip xxx.xxx.xxx.xxx (use your IP here)
=> run findfdt
=> run init_console
=> run args_mmc
=> pr bootcmd
bootcmd=if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run en
vboot; run distro_bootcmd
=> pr bootargs
bootargs=console=ttyO3,115200n8 root=PARTUUID=0001aabc-02 rw rootfstype=ext4 rootwait
=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.2.20 (1205 ms)
Using cpsw device
TFTP from server 192.168.2.1; our IP address is 192.168.2.20
Filename 'zImage'.
Load address: 0x82000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
####
2.3 MiB/s
done
Bytes transferred = 3871232 (3b1200 hex)
=> run netloadfdt
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.2.1; our IP address is 192.168.2.20
Filename 'am335x-icev2.dtb'.
Load address: 0x88000000
Loading: ###
2.2 MiB/s
done
Bytes transferred = 37204 (9154 hex)
=> bootz ${loadaddr} - ${fdtaddr}
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8df04000, end 8df10153 ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.14.79-ge669d52447 (oe-user@oe-host) (gcc version 7.2.1 20171011 (Lina
ro GCC 7.2-2017.11)) #1 PREEMPT Sat Apr 6 03:14:17 UTC 2019
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TI AM3359 ICE-V2 - dual CPSW
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 48 MiB at 0x8a800000
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] AM335X ES2.1 (neon)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64960
[ 0.000000] Kernel command line: console=ttyO3,115200n8 root=PARTUUID=0001aabc-02 rw rootfstype=e
xt4 rootwait
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)

I hope this helps you move forward.

Hi Ron,

Thanks for setting up the environment and trying to boot TMDSICE_v2 over TFTP.

I have set up the hardware as you have indicated with both the ethernet connection and the jumper settings.

I am using a network with a router where my server ( host Ubuntu ) is receives IP address 192.168.2.60 from the router on the network, and if TMDSICE_v2 boots from SD card, it receives the IP address 192.168.2.63. I have not set up static IP addresses for either, but the router does this every time. If necessary, I could make both static ips, but I don't think it will make any difference.

When I run the procedure that you have sent, I follow it to the T until I get to where I have to start dhcp by issuing => dhcp. 

Here is what I get after the command;

link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.2.64 (11 ms)
=>

So, I hook up immediately but curiously, the client ( TMDSICE_v2 ) receives an IP address which is unusual, and the boot process does not proceed. I have typed tftp after this and issued the command, but while the TFTP prompt comes up, and there are multiple tries, the boot process does not proceed.

I have installed dhcp on my host computer this morning. I am removing it to see if there is a conflict between the dhcp server on the host and the dhcp server on the router that is on the network. 

Will provide you with further update after this.

Hi Ron,

I removed the dhcp-server installed on my host PC and it had no effect. The same outcome as before. 

Anything that might be different between your settings and mine?

Thanks again.

Hi Ron,

The process worked. I forced the client IP address through static IP to 192.168.2.64 and inserted a tftp command after executing dhcp. I could download the image and start the boot process. It is now booting from tftp.

Thanks 

I will close the case. I left this note to make let other readers know that the issues were resolved.

Thanks