UBL or U-Boot

Naveed Alam said:

Do I need U-Boot as well to start a Linux kernel?

Yes, U-Boot is the actual kernel loader, the UBL is just a loader for U-Boot. UBL is necessary because U-Boot itself is typically too large to fit in the internal memory that would be available when the board first boots, so UBL which will fit in the internal memory is loaded instead so that the external memory can be initialized such that U-Boot can be loaded and executed which leads to the multi stage boot process you see in these devices (UBL -> U-Boot -> uImage(kernel) -> file system (application)).

Naveed Alam said:

Is UBL enough to initialize the board up to Linux loading point?

No, the UBL just does the most basic initialization to allow U-Boot to load.

Naveed Alam said:

If U-Boot does something more, what's that?

There may be even more to it, but at a minimum U-Boot provides additional flexibility and utility when booting the kernel, for example it has enough network capability to load a kernel image over the network, and has a simple command shell so that you can control U-Boot and the resulting kernel boot (including kernel boot arguments) from a UART terminal. It may be possible to get UBL to boot a kernel image instead of U-Boot with modification, however I have not seen this done before and there may be some unforseen limitation that would make this impractical. I am curious why you would want to take U-Boot out of the equation?

You could hack things around so that UBL loads Linux directly, but that's not for beginners.  The reason to want U-Boot is to get flexibility, including the ability to do things like scripted flash updates, in the boot sequence.  If your board is running U-Boot you can get code to it through UART and Ethernet (and someday, MMC); update flash if you like; run diagnostics programs; and more.  If you trash the operating system on your board, you'll have U-Boot to fall back on.

U-Boot sets up a few things that Linux needs, like the parameters in R0 and R1 (board type, ATAG pointer), the ATAGs used to pass memory information and command line arguments, and maybe a few other things.  That's stuff you could hard-wire into the pre-Linux stages of boot, if for some reason the value of saving a few blocks of flash and a handful of milliseconds at boot time seems too much, and if you have other solutions (like JTAG in the field) for system recovery and upgrade.

Assuming your board uses the same parts and is connected per DM355 EVM schematics, you should not need to change u-boot; however, we find that in most commonly, customers will place a different NAND flash device on their boards (due to availability, flash size requirements for their app, ...), some may also choose a different EMAC PHY...  Bottom line, any external DM355 component which deviates from DM355 EVM may need corresponding source code changes, not only in u-boot, but also at the Linux kernel level. 

For now, let us focus on u-boot.  By default, u-boot uses NAND, UART, DDR2, and EMAC (it also initializes internal DM355 hardware, but this can remain the same on your project); change any of these and you will likely need to change u-boot.  The source code for u-boot is normally distributed as part of DVSDK (this is the case for DM355) and can be found under PSP directory

dvsdk_1_30_00_31/PSP_X_XX_XX_XXX/board_utilities  (if I recall correctly)

once you untar the u-boot source code; there should be a README.txt that instructs you and how to rebuild the u-boot source code; I have not done this in a while but it should be something similar to

> make mrproper

> make dm355_config

> make

I hope this helps point you in the right direction