Hi guys, forgive me if this is too trivial but apparently, it is not for me. Here it goes...
I downloaded the sources for [at91bootstrap v1.15]ftp://www.at91.com/pub/at91bootstrap/AT91Bootstrap1.15 and [uboot1.3.4]http://ftp.denx.de/pub/u-boot/u-boot-1.3.4.tar.bz2, and also the [uboot-patch]ftp://www.at91.com/pub/uboot/u-boot-1.3.4-exp/u-boot-1.3.4-exp.diff.
Now my development board is not identical to 9260-ek board, but similar. Such as, my dataflash chip is on SPI0 cs1 unlike the 9260-ek board. So using some minimal modifications I got the bootstrap working for my board. I also tested if SDRAM is getting initialized or not by writing some locations and reading them back, that works.
So now the problem is that the bootstrap runs but uboot does not (without any sign of what is going wrong). What bugs me most is that I was unable to find good documentation about the structure of uboot and how it works. If someone does know where to find it, please let me know. Going to try to run uboot directly from SDRAM to see if that works. Any other suggestions are welcome too, thanks.

hello,
this is the hp:
http://www.denx.de/wiki/U-Boot

thanks dude.
There's another thing, I have to put the u-boot binary at the address mentioned in the bootstrap ( Desktop/test/Bootstrap-v1.15/board/at91sam9260ek/dataflash/at91sam9260ek.h, line

to be precise) , is that correct ? If yes, what about the u-boot environment ? Getting started page says it has to be stored at address 0x4200. Do we have to store it ? If yes, then how ?

When you do a saveenv command from uboot, that memory location is where it stores the environment. You should be able to run uboot without an initial environment as it will then just use default settings. Once you have the environment set up the way you want it, you can read that memory space and save it to a file that can be downloaded to a new system.

thanx falingtrea, that solves lot of my doubts.

So is thr any way to check if my bootstrap is loading u-boot in SDARM or not ?
I also tried running u-boot directly from SDRAM (using SAM-BA), but failed thr too
Means the problem is in u-boot coding itself. Also tried turning the debugging messages ON, but with same result.
Now going to try to trace the program execution sequence to better understand the code.
please let me know anything which you think that might help my situation.
One more thing, where is the main function of uboot ? where it all starts...

U-boot is low level OS for basic manipulation of the system. It can also serve as a "second level bootstrap", since the at91sam9260 only has 4k of memory it can boot from. So you load a very small bootstrap that loads u-boot, and then u-boot loads the OS.

Also, I found that u-boot needs to be loaded at a specific memory in order to work. It is loaded to the upper part of the SDRAM memory, at 0x23F00000. For some reason it would not run if loaded at x020000000.

U-Boot is not an OS (operating system).
U-Boot is a stand-alone (i.e. self- contained) program.


That is because U-Boot is not a relocatable program.

The first stage bootloader, at91bootstrap, has no relocation capability. So the binary it loads, such as U-Boot, has to be built to run at the specific or absolute (physical) memory address that the binary is loaded at.
Note that the uImage that contains the kernel is relocatable, but the Linux kernel for ARM (after uncompression by the U-Boot wrapper code) is not relocatable.

If you don't understand the difference between relocatable and absolute programs, then study up on linking (as in compile, assemble and link).

Regards

Those are two different things (for a stand-alone C program like U-Boot).
I haven't looked at v1.3 source, but the main procedure of U-Boot is probably (like most C programs) in main.c in the common directory.

For where "it all starts", you should look at the file u-boot.map, and you'll probably find out that the program start address (defined by TEXT_BASE in board/at91sam9260ek/config.mk) is in cpu/arm926ejs/start.s.

Regards

thanks for ur replies guys, really appretiate it.
Well, I started tracing the code frm start.S like blue_z said (thanx again )and found that start_armboot() was being called (bcoz I configured for arm of course...).
This particular function calls lowlevel_init() which actually skips all lowlevel initialization justifying that all the init was done by bootstrap.
So I thought my bootstrap isn't initializing properly, so I borrowed ready-made u-boot binary frm a friend and tried loading that using my bootstrap. And guess what, it worked !!! pity we dn't have that source to study. And to complicate the matters I found out later that, that u-boot was configured for 20MHz crystal, which worked flawlessly on my 18.432 MHz board, I have no clue as to how ???
Anyway, I'll leave that for later, the bottom line is that my bootstrap works, bringing me back to my u-boot.
Still trying to get through, just thought I shud update.

maybe I'm asking this in the wrong section. If yes, plz let me know whr exactly to post it...

In the source USART3 is selected for debug. But in pio setup actually DBGU pins are being set-up. So will this serial interface print on DBGU or USART3 ?
While initialization (serial_init() ), it's configuring things which are not relevant to DBGU, like character length, no. of stop bits, parity which are constant for DBGU. This is why I'm confused.
I think it should work for DBGU, but still want to be sure...

come on guys...

#define CONFIG_ATMEL_USART 1
#undef CONFIG_USART0
#undef CONFIG_USART1
#undef CONFIG_USART2
#define CONFIG_USART3 1 /* USART 3 is DBGU */

The comment says it... Do not ask why someone (at Atmel?) designed it like that...

If your u-boot "at91sam9260.h" does not have the comment, you are not using the current u-boot.

Reinhard

It is possible that this is just lazy programming by whoever wrote the Atmel code. They may have only defined 4 usarts, even though the 9G20 has 5 usarts plus a debug usart. What is really inportant is what memory space is defined for each of the usarts.

In fact. looking at the atmel_serial.c code, it only refernences "uart3" so the debug serial port looks like it is the only one set up and running in uboot.