How to boot bare board binary from U-Boot?

Question

How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot. My requirement is to reinitialize the

Answer 1

1. You can create the boot.bin with fsbl, bitstream, uboot.elf and you applications. Then flash in the QSPI flash and choose to boot from it.
2. Or you can boot from TFTP. Here you need to create the boot.bin just with fsb, bitstream, and uboot.elf. You need the change the uboot header file to force it boot from tftp like tftpboot 0x0 hello.elf. Once booted it will grab the elf/bin file with tftp and boot the board with bootelf or go command.
3. The same you can boot from SD card if there is one.

Answer 2

How to boot bare board binary from U-Boot?

Use U-Boot's go command to execute any kind of standalone program.

How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot.

Use U-Boot's go command to execute any kind of standalone program.

... I should load my binary from LAN network using "tftp" command.

Use U-Boot's tftpboot and go commands to execute any kind of standalone program. (The abbreviated tftp command has been deprecated now that there's also a tftpput command.)

Here problem is when I use go command my program has to use U-Boot service functions(I mean standalone binaries will run in U-Boot environment)...

You're misinformed, there is no requirement that you have to "use U-Boot service functions".
Build your standalone program independently of U-Boot, and it will execute completely independent of U-Boot.

But I can't boot using bootm or any other boot commands provided by U-Boot as my binary is not in kernel format.

There is no "kernel format"; that's why U-Boot uses the mkimage wrapper to identify binaries.
The bootm command is designed specifically for the booting requirements of OSes such as the Linux kernel (e.g. a buffer containing the command line parameters) by specifying the characteristics of the binary.
Use U-Boot's go command to execute any kind of simple, standalone program.

If you have issues executing your binary when using the go command, then the problem lies with your program, e.g. taking control of the processor and initializing its C environment.

ADDENDUM
When I use the term standalone program, I'm referring to the generic definition (aka bare-metal), and not the U-Boot-specific definition related to its examples/ directory.
FWIW I have used the go command for both kinds of "standalone" programs.
U-Boot describes its "standalone" as

 * "Standalone Programs" are directly runnable in the environment
 *   provided by U-Boot; it is expected that (if they behave
 *   well) you can continue to work in U-Boot after return from
 *   the Standalone Program.

Note that the use of the U-Boot environment is optional.
A standalone program is not required to use the U-Boot environment, especially if there is no intention of returning back to U-Boot.
There is nothing in U-Boot to detect or restrict the behavior of a standalone program.

If you cannot get your standalone program to work with the go command, then the problem lies with your program, and not the go command.
The go command merely transfers control (i.e. a branch instruction to the specified memory location), and places no restrictions or requirements whatsoever on that code (other than what is sensible for operation of the system).

Use an in-circuit emulator (ICE) or JTAG debugger to resolve problems with your code, especially when your program does not use the existing stack.

ADDENDUM 2
Instead of the ambiguous go command, the mkimage wrapper does provide for the standalone image-type for use with the bootm command.
See Creating a bare metal boot image, but don't expect different results from a go command.
The advantages of using a wrapper and bootm over go is that the downloaded image (a uImage file) can be:

• identified/verified with the iminfo command,
• compressed (e.g. gzip, bzip2, lzo) or uncompressed.