SK-AM64: Booting over ethernet not working for AM64x

Hi,

At the moment this appears to a permissions issue with the server, perhaps the files or directory or server setup not pointing to the right directory. I would recommend to tftp say the image file after u-boot is loaded when it is configured for SD card boot. I don't have a board handy at the moment other I could give exact commands so here are the suggested ones.

- setenv autoload n

- dhcp 

- setenv severip (your tftp server)

The next command would be to do the tftp to test the server. I don't remember the exact command but print out the u-boot environment with a print command from the u-boot command line. Review that for an example tftp command.

Best Regards,

Schuyler

Hello Schuyler,

you were right, port 69 was blocked by the firewall, I thought it was opened by setup script but I was wrong.

So now I am able to transfer the files over Ethernet, anyway I run into an odd behavior: even though I have followed the steps described in the guide and even though I have modified the files "uEnv_ethernet_ospi-nor_am64xx-evm.txt" and "am64x_evm_a53_defconfig" accordingly, when I try to boot from flash I see that the u-boot commands listed in the above uEnv file are run again, the files are transferred again from ethernet and flashed again to ospi but Linux never boots.

If I try to force boot the image by typing booti cmd from the terminal, I get Bad Linux ARM64 Image magic from the board.

What should I do to debug this problem? Am I doing something wrong during the file transfer?

Thank you for your help,

Paolo

Hi,

I will need to bring in another team member. Just so we are aligned could you please indicate which steps you are following in the SDK user guide?

Best Regards,

Schuyler

Absolutely.

All the steps described refer to Linux SDK 09.00.00.03.

1. updated CONFIG_BOOTCOMMAND as in 3.5.2.3.
2. build u-boot as in 3.1.1.1.2.
3. move HS-FS files to /tftpboot as well as uEnv.txt file specified in step 1.
4. move Image to /tftpboot.
5. set switches on AM64-SK for Eth boot.
6. files are transferred, confirmed this with Wireshark.
7. set switches to OSPI boot.
8. I see from terminal that u-boot is starting, but then when uEnv gets evaluated another TFTP transfer is performed and the Linux system doesn't start.

Some considerations:

• do I need 2 sets of bootloaders? one set modified to allow ethernet boot and flashing as described in steps 1 - 2, and another set for loading from OSPI?
• I found on Linux academy the following guide for flashing Linux to OSPI but from SD card: https://dev.ti.com/tirex/explore/node?node=A__AJ18sLHn3k.q.KnopPVnKw__linux_academy_am64x__7qm9DIS__LATEST&search=am64 , is it portable also for flashing from network?
• In the above guide there is a process called ubinize, which I did not do. Is it the missing step?

thank you,

Paolo

Hi,

Thank you for providing the steps. Please allow a day or two for me to review with team members.

Best Regards,

Schuyler

Hello Schuyler,

any news about this?

Best regards,

Paolo

Is this thread still active?
Please I would appreciate an update on the status.

Best regards,
Paolo

Hi, 

Looking at the steps and what you have done and your question related to having multiple boot configs. If you are only trying to put the images into flash my initial thinking is that you don't have to build the ethernet boot unless you plan to boot from Ethernet. 

So I would like to confirm that you end goal here is to merely program OSPI to boot from that interface on the TI EVM. Or is your work here about programming a custom board?

Best Regards,

Schuyler

My end goal is to be able to flash the firmware via Ethernet, right now on SK-AM64, later on on a custom board when the hardware will be ready.

My understanding is that tiboot, tispl, u-boot and Linux image need to be flashed.

As of now I am able to flash tiboot, tispl and u-boot, but I always incur in an error when I flash the linux image as well. In particular the error is "Bad Linux ARM64 Image magic" and I get this error when I set the board to boot from OSPI (refer above for the steps provided).

Best regards,
Paolo Mattachini

So the U-Boot images are working but U-boot is detecting a bad image. If you still have u-boot prompt after the bad image message could you please attach the results for print? I would like to the u-boot environment. What I am looking for is if the OSPI address where the kernel is stored matches the programming address. Since u-boot images are running out of SPI I wonder if there an difference between where the kernel is stored and where U-Boot thinks it is stored.

Best Regards,

Schuyler