[U-Boot-Users] Replacing AT91 u-boot

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

Hello,
I'm sorry but I am still facing to problems trying to replace the existing u-boot-0.3.2 with the latest 1.1.3 on a at91rm9200dk board.
I built u.boot
 make at91rm9200dk_config
 make
then I reomved R159 from the board and booted,
then I sent loader.bin (found on Atmel website)
then I send the just builded u-boot.bin
but at this point the AT91 system freezes showing few random characters on the serial console.

If I use the original u-boot.bin 0.3.2 everything is ok,
what am I missing ?

Thank you for your time

----

loader 1.0 (Aug  8 2003 - 12:01:07)                                             
                                                                                
XMODEM: Download U-BOOT                                                         
C                                                                               
U-Boot downloaded successfully                                                  
                                                                                
                                                                                
U-Boot 0.3.2 (Jun 24 2003 - 17:04:08)                                           
                                                                                
U-Boot code: 21F00000 -> 21F14160  BSS: -> 21F1FAEC                             
DRAM Configuration:                                                             
Bank #0: 20000000 32 MB                                                         
Atmel: AT49BV1614A (16Mbit)                                                     
Flash:  2 MB                                                                    
DataFlash:AT45DB642                                                             
Nb pages:   8192                                                                
Page Size:   1056                                                               
Size= 8650752 bytes                                                             
Logical address: 0xC0000000                                                     
Uboot>  

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INMS8J$2142277E56B095AE5F8745868A53E29F@libero.it> you wrote:
>
> I'm sorry but I am still facing to problems trying to replace the
>  existing u-boot-0.3.2 with the latest 1.1.3 on a at91rm9200dk board.
...
> then I sent loader.bin (found on Atmel website)

Why are you doing this? If you have U-Boot running, you can just  use
the  existing old version to download and install the new image. This
is a trivial procedure.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
                                                   - Arthur C. Clarke

[U-Boot-Users] Replacing AT91 u-boot

[Peter Menzebach]

kentropy wrote:
> Hello,
> I'm sorry but I am still facing to problems trying to replace the existing u-boot-0.3.2 with the latest 1.1.3 on a at91rm9200dk board.
> I built u.boot
>  make at91rm9200dk_config
>  make
> then I reomved R159 from the board and booted,
> then I sent loader.bin (found on Atmel website)
> 
> then I send the just builded u-boot.bin
> but at this point the AT91 system freezes showing few random characters on the serial console.
> 
> If I use the original u-boot.bin 0.3.2 everything is ok,
> what am I missing ?
> 
I am starting here, because later in the thread was to much mismatch 
between the 2 different ways to boot the system:

1. Booting u-boot from the parallel flash
The board is delivered with this option. Here it should be possible to 
simply replace u-boot in the parallel flash. Please check the serial and 
PLL settings.

2. Booting from serial dataflash (romboot, u-boot, kernel, rootfs in 
dataflash)
Principle shown in:
http://www.atmel.com/dyn/resources/prod_documents/doc6067.pdf

Only for this procedure you have to remove R159!

Here *no* program can be executed directly, since the flash is *serial*.

Here we have a multi-stage boot process:
1. Internal ROM services are finding ARM vector in dataflash and start 
downloading "romboot.bin" from serial dataflash to SRAM
2. romboot starts and sets up processor, RAM+serial
3. romboot loads u-boot from serial dataflash to RAM
4. romboot starts u-boot
5. u-boot loads+starts uImage from serial dataflash to RAM and starts it 
(bug in common/cmd_bootm.c, patch: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1072345&group_id=65938&atid=512789)
6. rootfs can be jffs2 in dataflash, newest mtd sources from mtd cvs needed

The romboot delivered by Atmel didn't set up the PLLs correctly, I don't 
know, if they corrected it on their website. A replacement for 
romboot.bin compilable with gnuc is here:

http://www.mw-itcon.de/patches/romboot.tgz

Please check always memory addresses, PLL and serial settings in the 
configs of romboot, u-boot and kernel.

I can definitely confirm, that u-boot-1.1.2 works fine in that case. If 
needed, I can send you the u-boot config.

Hope, that helps a step further...
Peter

-- 
Peter Menzebach
Menzebach und Wolff IT-Consulting GbR
Phone +49 751 355 387 1

[U-Boot-Users] Replacing AT91 u-boot

[Peter Menzebach]

kentropy wrote:
> Hello,
> I'm sorry but I am still facing to problems trying to replace the existing u-boot-0.3.2 with the latest 1.1.3 on a at91rm9200dk board.
> I built u.boot
>  make at91rm9200dk_config
>  make
> then I reomved R159 from the board and booted,
> then I sent loader.bin (found on Atmel website)
> 
> then I send the just builded u-boot.bin
> but at this point the AT91 system freezes showing few random characters on the serial console.
> 
> If I use the original u-boot.bin 0.3.2 everything is ok,
> what am I missing ?
> 
I am starting here, because later in the thread was to much mismatch
between the 2 different ways to boot the system:

1. Booting u-boot from the parallel flash
The board is delivered with this option. Here it should be possible to
simply replace u-boot in the parallel flash. Please check the serial and
PLL settings.

2. Booting from serial dataflash (romboot, u-boot, kernel, rootfs in
dataflash)
Principle shown in:
http://www.atmel.com/dyn/resources/prod_documents/doc6067.pdf

Only for this procedure you have to remove R159!

Here *no* program can be executed directly, since the flash is *serial*.

Here we have a multi-stage boot process:
1. Internal ROM services are finding ARM vector in dataflash and start
downloading "romboot.bin" from serial dataflash to SRAM
2. romboot starts and sets up processor, RAM+serial
3. romboot loads u-boot from serial dataflash to RAM
4. romboot starts u-boot
5. u-boot loads+starts uImage from serial dataflash to RAM and starts it
(bug in common/cmd_bootm.c, patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1072345&group_id=65938&atid=512789)
6. rootfs can be jffs2 in dataflash, newest mtd sources from mtd cvs needed

The romboot delivered by Atmel didn't set up the PLLs correctly, I don't
know, if they corrected it on their website. A replacement for
romboot.bin compilable with gnuc is here:

http://www.mw-itcon.de/patches/romboot.tgz

Please check always memory addresses, PLL and serial settings in the
configs of romboot, u-boot and kernel.

I can definitely confirm, that u-boot-1.1.2 works fine in that case. If
needed, I can send you the u-boot config.

Hope, that helps a step further...
Peter

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> Why are you doing this? If you have U-Boot running, you can just  use
> the  existing old version to download and install the new image. This
> is a trivial procedure.

Wolfgang, thank you for answering.
I have done as you suggested, but now the board don't boot (I am going to install the old u-boot)
I don't understand why the default configuration for at91rm9200dk is  don't work on my board, after 3 days I'm still unable to use 1.1.3 :-(
BTW the u-boot.gz I am sending here is created with gzip-ping u-boot.bin

These are the commands I've done:

Uboot> loadb 20000000
...SEND BOOT.BIN...
## Ready for binary (kermit) download to 0x20000000 at 115200 bps...                                                                    
## Total Size      = 0x00002908 = 10504 Bytes                                             
## Start Addr      = 0x20000000                               
Uboot> cp.b 20000000 10000000 5fff
Copy to Flash... done

Uboot> protect on 10000000 10005fff
Protected 3 sectors

Uboot> loadb 20000000
...SEND U-BOOT.GZ...
## Ready for binary (kermit) download to 0x20000000 at 115200 bps...
## Total Size      = 0x0000b9a9 = 47529 Bytes
## Start Addr      = 0x20000000

Uboot> protect off 10010000 1001ffff
Un-Protected 1 sectors

Uboot> erase 10010000 1001ffff
Erase Flash from 0x10010000 to 0x1001ffff Erasing sector  8 ... ok.
Erased 1 sectors

Uboot> cp.b 20000000 10010000 ffff
Copy to Flash... done

Uboot> protect on 10010000 1001ffff
Protected 1 sectors
Uboot>

...here resetting...

boot 1.0 (Aug  8 2003 - 12:29:00)
Uncompressing image...

...frozen...

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> Why are you doing this? If you have U-Boot running, you can just use
> the existing old version to download and install the new image. This
> is a trivial procedure.

Wolfgang, thank you for answering.
I have done as you suggested, but now the board don't boot (I am going to install the old u-boot)
I don't understand why the default configuration for at91rm9200dk is don't work on my board, after 3 days I'm still unable to use 1.1.3 :-(
BTW the u-boot.gz I am sending here is created with gzip-ping u-boot.bin

These are the commands I've done:

Uboot> loadb 20000000
...SEND BOOT.BIN...
## Ready for binary (kermit) download to 0x20000000 at 115200 bps...
## Total Size = 0x00002908 = 10504 Bytes
## Start Addr = 0x20000000
Uboot> cp.b 20000000 10000000 5fff
Copy to Flash... done

Uboot> protect on 10000000 10005fff
Protected 3 sectors

Uboot> loadb 20000000
...SEND U-BOOT.GZ...
## Ready for binary (kermit) download to 0x20000000 at 115200 bps...
## Total Size = 0x0000b9a9 = 47529 Bytes
## Start Addr = 0x20000000

Uboot> protect off 10010000 1001ffff
Un-Protected 1 sectors

Uboot> erase 10010000 1001ffff
Erase Flash from 0x10010000 to 0x1001ffff Erasing sector 8 ... ok.
Erased 1 sectors

Uboot> cp.b 20000000 10010000 ffff
Copy to Flash... done

Uboot> protect on 10010000 1001ffff
Protected 1 sectors
Uboot>

...here resetting...

boot 1.0 (Aug 8 2003 - 12:29:00)
Uncompressing image...

...frozen...

TIA

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INOL40$6FF461974C374A63A2E5C94AB9FA51CC@libero.it> you wrote:
>
> I don't understand why the default configuration for at
> 91rm9200dk is don't work on my board, after 3 days I'm still unable to us
> e 1.1.3 :-(
> BTW the u-boot.gz I am sending here is created with gzip-ping u-boot.bin

You are not suppoesed to compress the u-boot.bin  file;  "u-boot.bin"
is a raw bbianry which can be directly run on the board. You must not
modiify it.

> Uboot> loadb 2000000
> 0
> ...SEND BOOT.BIN...

Why are you doing this? You should just store the u-boot.bin file  in
flash. Forget about boot.bin - it is not needed.

> Uboot> loadb 20000000
> ...SEND U-BOOT.GZ...

Wrong. Use the unmodified u-boot.bin file.

> Uboot> protect off 10010000
>  1001ffff
> Un-Protected 1 sectors
> 
> Uboot> erase 10010000 1001ffff
> Eras
> e Flash from 0x10010000 to 0x1001ffff Erasing sector 8 ... ok.
> Erased 1
> sectors
> 
> Uboot> cp.b 20000000 10010000 ffff
> Copy to Flash... done

Wrong again. On ARM systems like the at91rm9200dk the reset vector is at address 0x000, so U-Boot must be stored at this address.

Copy the u-boot.bin image to the addresses starting at 0x0000.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Repeat after me:
Usenet is not a word processor; it's a medium where aesthetics count.
Mozilla is not a newsreader; it's a web browser.
Windows is not an operating system; it's a GUI on a program loader.
         -- Tom Christiansen in <6bq0g5$lr4$2@csnews.cs.colorado.edu>

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> Why are you doing this? You should just store the u-boot.bin file  in
> flash. Forget about boot.bin - it is not needed.

Great news

> Wrong. Use the unmodified u-boot.bin file.

Yesssss.

> Wrong again. On ARM systems like the at91rm9200dk the reset vector is at address 0x000, so U-Boot must be stored at this address.
> 
> Copy the u-boot.bin image to the addresses starting at 0x0000.

As with every ARM based board, ok
I wondered why Atmel used a so tricky boot methos instead of using only u-boot ;-)

YEAH !
Now is perfect (except for a weird CRC error message:

U-Boot 1.1.3 (Sep 30 2005 - 15:33:58)

U-Boot code: 21F00000 -> 21F172AC  BSS: -> 21F1B968
RAM Configuration:
Bank #0: 20000000 32 MB
Atmel: AT49BV1614A (16Mbit)
Flash:  2 MB
DataFlash:AT45DB642
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C0007FFF (RO)
Area 1: C0008000 to C001FFFF (RO)
Area 2: C0020000 to C0027FFF
Area 3: C0028000 to C083FFFF
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
U-Boot>

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INPBUU$09053155FF9463E42DE4C4C2F582AC88@libero.it> you wrote:
>
> Now is perfect (except for a weird CRC error message:
...
> *** Warning - bad CRC, using default environment

See FAQ at http://www.denx.de/twiki/bin/view/DULG/WarningBadCRC


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."                            - Harv Masterson

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

Now I have u-boot-1.1.3 on AT91RM9200DK, but something is still going wrong :-(

U-Boot 1.1.3 (Sep 30 2005 - 15:33:58)

U-Boot code: 21F00000 -> 21F172AC  BSS: -> 21F1B968
RAM Configuration:
Bank #0: 20000000 32 MB
Atmel: AT49BV1614A (16Mbit)
Flash:  2 MB
DataFlash:AT45DB642
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes
Logical address: 0xC0000000
Area 0:	C0000000 to C0007FFF (RO)
Area 1:	C0008000 to C001FFFF (RO)
Area 2:	C0020000 to C0027FFF 
Area 3:	C0028000 to C083FFFF 
In:    serial
Out:   serial
Err:   serial
U-Boot> printenv

bootdelay=3
baudrate=115200
ethaddr=00:02:a5:6e:3f:fd
filesize=3638c0
fileaddr=21140000
netmask=255.255.255.0
ipaddr=192.168.0.184
serverip=192.168.0.11
bootargs=root=/dev/ram rw initrd=0x21100000,6000000 ramdisk_size=15360 console=ttyS0,115200 mem=32M
stdin=serial
stdout=serial
stderr=serial

Environment size: 294/8188 bytes
U-Boot> tftp 21000000 uImage

TFTP from server 192.168.0.11; our IP address is 192.168.0.184
Filename 'uImage'.
Load address: 0x21000000
Loading: *\b#################################################################
	 ##############################################################
done
Bytes transferred = 646841 (9deb9 hex)
U-Boot> tftp 21100000 ramdisk

TFTP from server 192.168.0.11; our IP address is 192.168.0.184
Filename 'ramdisk'.
Load address: 0x21100000
Loading: *\b#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #############################################
done
Bytes transferred = 3553472 (3638c0 hex)
U-Boot> bootm 21000000

## Booting image at 21000000 ...
   Image Name:   
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    646777 Bytes = 631.6 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... 
[here is freezed]

Maybe into boot.bin there were some setting necessary for the system ?
AFAIK nobody (either Atmel) uses u-boot stored at the beginning of the flash (as many others ARM board producers do), but AT91 uses a pre-bootloader.
FYI, I have
ParallelFlash: AT49BV1614A
DataFlash: AT45DB642

Any help will be appreciated
TIA

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INPD6P$312004E151C9812F7DD3EEB54320D940@libero.it> you wrote:
> Now I have u-boot-1.1.3 on AT91RM9200DK, but something is still going wrong :-(

Yes. The problem is: You did not read the manual.

> U-Boot> tftp 21000000 uImage
...
> U-Boot> tftp 21100000 ramdisk

So it seems you want to boot a Linux kernel with root file system  in
a ramdisk image, but then...

> U-Boot> bootm 21000000

...I did not see where you defined your "bootargs" variable, and  the
correct  boot comand for using a ramdisk has two arguments instead of
one.

> May be into boot.bin there were some setting necessary for the system ?

Nargh. Please forget boot.bin. You will not need it any more.

> AFAIK nobody (either Atmel) uses u-boot stored at the beginning of the flash
> (as many others ARM board producers do), but AT91 uses a pre-bootloader.

I don't know where you got this "knowledge" from, but it is plain wrong.

> Any help will be appreciated

Help yourself. Read the manual.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't see any direct evidence ...  but, then, my crystal ball is in
dire need of an ectoplasmic upgrade. :-)              -- Howard Smith

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> ...I did not see where you defined your "bootargs" variable, and  the
> correct  boot comand for using a ramdisk has two arguments instead of
> one.

Sorry I'm confused, why these settings won't be enough ?

U-Boot> printenv

bootdelay=3
baudrate=115200
ethaddr=00:02:a5:6e:3f:fd
filesize=3638c0
fileaddr=21140000
netmask=255.255.255.0
ipaddr=192.168.0.184
serverip=192.168.0.11
bootargs=root=/dev/ram rw initrd=0x21100000,6000000  
  ramdisk_size=15360 console=ttyS0,115200 mem=32M
stdin=serial
stdout=serial
stderr=serial

TIA

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INQ2HM$D2D46307DC82D8C137D94D5EAE71607A@libero.it> you wrote:
>
> Sorry I'm confused, why these settings won't be enough ?

Sorry, I missed this.

> bootargs=root=/dev/ram rw initrd=0x21100000,6000000  ramdisk_size=15360 console=ttyS0,115200 mem=32M

Remove the initrd= and mem= part. U-Boot passes correct ATAGS to  the
kernel.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If God had a beard, he'd be a UNIX programmer.

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> Sorry, I missed this.
> Remove the initrd= and mem= part. U-Boot passes correct ATAGS
> to  the kernel.

Thank you again.
I followed your suggestions:

U-Boot> printenv
bootdelay=3
baudrate=115200
ethaddr=00:02:a5:6e:3f:fd
filesize=3638c0
fileaddr=21140000
netmask=255.255.255.0
ipaddr=192.168.0.184
serverip=192.168.0.11
bootargs=root=/dev/ram rw ramdisk_size=15360 console=ttyS0,115200
stdin=serial
stdout=serial
stderr=serial

U-Boot> tftp 21100000 ramdisk
TFTP from server 192.168.0.11; our IP address is 192.168.0.184
Filename 'ramdisk'.
Load address: 0x21100000
Loading: ###
.snip.
########
done
Bytes transferred = 3553472 (3638c0 hex)

U-Boot> tftp 21000000 uImage
TFTP from server 192.168.0.11; our IP address is 192.168.0.184
Filename 'uImage'.
Load address: 0x21000000
Loading: ##############################################
        #######################################
done
Bytes transferred = 646841 (9deb9 hex)

U-Boot> bootm
## Booting image at 21000000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    646777 Bytes = 631.6 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ...

[here is still freezed]

Every test I do I'm more confused.
Please apologize my question, but did you ever used an AT91RM9200DK board with u-boot (reading help and your site seems that you are a PPC expert but there is no examples using AT91) ?
Why Atmel give out and say to use boot.bin as pre-bootloader and you say not ?
Why the u-boot-1.1.3 default configuration for this board don't work ?
Maybe there is something missing or wrong ?
TIA

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INQMN6$BA1EA9D7C1AEB9F5F48178400D2F533D@libero.it> you wrote:
>
> Every test I do I'm more confused.
> Please apologize my question, but did you ever used an AT91RM9200DK board
> with u-boot (reading help and your site seems that you are a PPC expert
> but there is no examples using AT91) ?

My own ARM knowledge is indeed limited, but there are other engineers
in our team who know exactly  what  they  are  doing;  DENX  supports
PowerPC, ARM and MIPS.

And yes, I did. Here is an  example  (not  exactly  the  AT91RM9200DK
board  but  the CMC_PU2, but there is no difference between these two
boards relevant to this discussion):

U-Boot 1.1.3 (Apr  6 2005 - 15:40:24)

U-Boot code: 20F00000 -> 20F18A38  BSS: -> 20F1D23C
RAM Configuration:
Bank #0: 20000000 16 MB
Board: CMC-PU2 (Rittal GmbH)
Flash:  8 MB
In:    serial
Out:   serial
Err:   serial
...
=> tftp 20800000 /tftpboot/cmcpu2/uImage
TFTP from server 192.168.1.1; our IP address is 192.168.20.1
Filename '/tftpboot/cmcpu2/uImage'.
Load address: 0x20800000
Loading: #################################################################
         #################################################################
         ########
done
Bytes transferred = 702805 (ab955 hex)
=> tftp 20900000 /tftpboot/cmcpu2/uRamdisk
TFTP from server 192.168.1.1; our IP address is 192.168.20.1
Filename '/tftpboot/cmcpu2/uRamdisk'.
Load address: 0x20900000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################################
done
Bytes transferred = 1502281 (16ec49 hex)
=> print bootargs
bootargs=root=/dev/ram rw ip=192.168.20.1:192.168.1.1:192.168.1.254:255.255.0.0:cmcpu2:eth0:off panic=1
=> bootm 20800000 20900000
## Booting image at 20800000 ...
   Image Name:   ARM Linux-2.4.27
   Created:      2005-07-11  15:13:23 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    702741 Bytes = 686.3 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading Ramdisk Image at 20900000 ...
   Image Name:   Simple Embedded Linux Framework
   Created:      2004-11-10   0:35:20 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    1502217 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

Linux version 2.4.27-vrs1-mk1 (mk at pollux) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)) #1 Mon Jul 11 17:10:44 MEST 2005
CPU: Arm920Tid(wb) revision 0
Machine: ATMEL AT91RM9200
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw ip=192.168.20.1:192.168.1.1:192.168.1.254:255.255.0.0:cmcpu2:eth0:off panic=1
Calibrating delay loop... 34.50 BogoMIPS
Memory: 16MB = 16MB total
Memory: 13068KB available (1299K code, 277K data, 56K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
CPU: Testing write buffer: pass
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 5 MTD partitions on "CMC PU2 flash":
0x00000000-0x00020000 : "Firmware"
0x00020000-0x00030000 : "Environment"
0x00030000-0x000f0000 : "Kernel"
0x000f0000-0x00780000 : "Filesystem 1"
0x00780000-0x00800000 : "Filesystem 2"
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
ttyS0 at MMIO 0xfefc0000 (irq = 6) is a AT91_SERIAL
ttyS1 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL
ttyS2 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL
ttyS3 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL
ttyS4 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL
eth0: Link now 100-FullDuplex
eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (f6:70:1d:61:b5:9d)
eth0: Davicom 9196 PHY (Copper)
AT91 Watchdog Timer enabled (5 seconds)
Found AT91 i2c
I2C: RS5C372 RTC driver successfully loaded
CMC buzzer driver $Revision: 0.2 $
CMC digital IO driver $Revision: 0.2 $
Serial driver version 0.03 (2004-12-17) with no serial options enabled
ttyS5 at 0xc2084000 (irq = 29) is a TI16752
ttyS6 at 0xc2086000 (irq = 30) is a TI16752
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
eth0: Link now 100-FullDuplex
IP-Config: Complete:
      device=eth0, addr=192.168.20.1, mask=255.255.0.0, gw=192.168.1.254,
     host=cmcpu2, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1467K
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 56K


BusyBox v0.60.5 (2004.11.10-00:31+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# cat /proc/cpuinfo 
Processor       : Arm920Tid(wb) rev 0 (v4l)
BogoMIPS        : 34.50
Features        : swp half thumb 

Hardware        : ATMEL AT91RM9200
Revision        : 0000
Serial          : 0000000000000000
# 


> Why Atmel give out and say to use boot.bin as pre-bootloader and you say not ?

There are several reasons. For example, Atmel supports  booting  from
dataflash, too, where a minimal bootstrap loader is necessary.

> Why the u-boot-1.1.3 default configuration for this board don't work ?

Why do you think so? From your postings it's clear that U-Boot  works
-  you can even load and start your kernel. It's just that your Linux
kernel is not working.

> Maybe there is something missing or wrong ?

Seems to be some problem with your kernel. Check the typical problems
on ARM systems, like if you're using a correct machine ID.  Attach  a
debugger  and  check  where  the kernel is hanging, and why. Etc. But
this actually is off topic here as it is unrelated to U-Boot.

The messages you showed make it clear that U-Boot *is*  running  fine
on your board.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Commitment, n.:      Commitment can be illustrated by a breakfast
of ham and eggs. The chicken was involved, the pig was committed.

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

Thank you again for your patience answering.

> The messages you showed make it clear that U-Boot *is*  running  fine
> on your board.

The thing I can't understand due to my inexperience is why using u-boot-0.3.2 with my kernel 2.6.13.2 everything worked
and simply changing u-boot-1.1.3 not.
So I suppose that the kernel is not the problem, but only the changed things: loader and u-boot.
Trying to guess: can the problem be caused by a different kind of SDRAM or Flash between my DK and your compatible one ?
TIA

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INR32H$47E4B006BBE324436EF5632378983CEB@libero.it> you wrote:
>
> The thing I can't understand due to my inexperience is why using u-boot-0.3.2
> with my kernel 2.6.13.2 everything worked
> and simply changing u-boot-1.1.3 not.

Many, many things have changed between 0.3.2 and 1.1.3; it  would  be
interesting  to know why and where your kernel is hanging. You should
attach a debugger and  actually  try  to  *devbug*  this  insetad  of
guessing (and blaming U-Boot).

> So I suppose that the kernel is not the problem, but only the changed things:
> loader and u-boot.
> Trying to guess: can the problem be caused by a different kind of SDRAM or Flash between my DK and your compatible one ?

No, definitely  not.  (Actually  I  can  run  the  same  tests  on  a
AT91RM9200DK,  but  this is not wired up for automatic testing in our
virtual lab, so I cannot run such tests remotely like I could  do  on
the cmc_pu2. But I know that it works exactly the same way.)

One of the things that did change is the mach-types.h file;  if  your
kernel  uses some invalid ID this could explain such a hang. But this
is wild guessing - please debug the problem.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It would be illogical to assume that all conditions remain stable
	-- Spock, "The Enterprise" Incident", stardate 5027.3

[U-Boot-Users] Replacing AT91 u-boot

[Andrey P. Vasilyev]

Hello!

On Sun, Oct 02, 2005 at 10:47:05PM +0200, kentropy wrote:
> The thing I can't understand due to my inexperience is why using u-boot-0.3.2 with my kernel 2.6.13.2 everything worked
> and simply changing u-boot-1.1..3 not.
> So I suppose that the kernel is not the problem, but only the changed things: loader and u-boot.
> Trying to guess: can the problem be caused by a different kind of SDRAM or Flash between my DK and your compatible one ?

When I tried to start linux kernel on my RM9200-based board, my main 
problem was in RomBoot.bin (it is, actually, a predecessor or successor of 
loader.bin) - it was setting up PLLs by wrong command sequence right 
before starting kernel, and all the kernel messages was transmitted on the 
wrong baudrate.
Try to start u-boot directly from parallel flash without any first-stage 
bootloader. It might help.

-- 
With best regards,
  Andrey Vasilyev

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

>You should
> attach a debugger and  actually  try  to  *devbug*  this
>  insetad  of guessing (and blaming U-Boot).

Ok, I won't guess anymore ;-)
But I don't know how to debug it, I have no debuggers.

> One of the things that did change is the mach-types.h file;  
> if  your
> kernel  uses some invalid ID this could explain such a hang. 
> But this
> is wild guessing - please debug the problem.

I verified that entries 
MACH_TYPE_AT91RM9200 and MACH_TYPE_AT91RM9200DK
are the same you found in kernel 2.6.13
and tried replacing MACH_TYPE_AT91RM9200DK
MACHINE_START(MACH_TYPE_AT91RM9200DK
with
MACHINE_START(MACH_TYPE_AT91RM9200
in board-dk.c without success.

[U-Boot-Users] Replacing AT91 u-boot

[Wolfgang Denk]

In message <INS0XG$F934761E0D2B4479602310BB5EBE96E1@libero.it> you wrote:
>
> Ok, I won't guess anymore ;-)
> But I don't know how to debug it, I have no debuggers.

Buy a BDI2000. It will pay off quickly. Not to mention the  (avoided)
loss of (increasingly grey) hair.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If only God would give me some clear sign! Like making a large  depo-
sit in my name at a Swiss Bank.                         - Woody Allen

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> > May be into boot.bin there were some setting necessary for the system ?
> 
> Nargh. Please forget boot.bin. You will not need it any more.
> 
> > AFAIK nobody (either Atmel) uses u-boot stored at the beginning of the flash
> > (as many others ARM board producers do), but AT91 uses a pre-bootloader.
> 
> I don't know where you got this "knowledge" from, but it is plain wrong.


Confusing news from AT91 website about boot.bin / loader.bin
[
You need to download a "boot.bin" into the first sector.
The boot.bin may need to know about which flash you are using.
loader.bin has the same problem.
.snip.
Ulf Samuelsson
]

[U-Boot-Users] Replacing AT91 u-boot

[Mirco Fuchs]

> Confusing news from AT91 website about boot.bin / loader.bin
> [
> You need to download a "boot.bin" into the first sector.
> The boot.bin may need to know about which flash you are using.
> loader.bin has the same problem.
> .snip.
> Ulf Samuelsson
> ]

AFAIK loader.bin is used to download boot.bin to RAM location. boot.bin
itself is an u-boot binary image. It is straight executed after
downloading. Now it's possible to install a new u-boot version.

Regards
Mirco

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date:
30.09.2005
 

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

> AFAIK loader.bin is used to download boot.bin to RAM location. 

Correct

> boot.bin itself is an u-boot binary image. 
> It is straight executed after
> downloading. Now it's possible to install a new u-boot version.

Definitely not.
BTW binary sizes are too different to say that
boot.bin is 10KB
loader.bin is 7KB
u-boot is 92KB

Referring to Atmel manuals boot.bin is a pre-loader ususlly stored at the beginning of flash (0x10000000) which calls u-boot (usually stored at 0x10010000).
You can found sources for loader.bin and boot.bin on Atmel CDROM and until last saturday on this website. 
http://www.at91.com/Pages/products/EvaluationBoard/AT91RM3400DK/at91rm3400dk.html#flash
Today these sources have been removed (I don't know why ?) 

[U-Boot-Users] Replacing AT91 u-boot

[kentropy]

Peter,
your explanation is fantastic ans exhaustive.

> Only for this procedure you have to remove R159!

Or if you destroy the existing u-boot in Parallel Flash ;-)


> I can definitely confirm, that u-boot-1.1.2 works fine in that case. If
> needed, I can send you the u-boot config.

Could you please send it to me ?


> Hope, that helps a step further...

Yes, sometimes help and readme aren't clear enough for newbies ;-)

[U-Boot-Users] Replacing AT91 u-boot

[Peter Menzebach]

fyi,
I just upgraded u-boot to latest cvs version. For starting from serial 
dataflash, you only have to set

CONFIG_ENV_IS_IN_DATAFLASH
CONFIG_SKIP_LOWLEVEL_INIT
CONFIG_SKIP_RELOCATE_UBOOT

and a small patch for arm920t/start.S. Then I could compile+flash u-boot 
and run it. I have not tested everything, but linux boots fine....

Best regards
Peter