[ AM1705 ] No kernel output after U-Boot load

sorry:

incorrect on the line:

"and enter loadm command:"

correct: "bootm" command

May be nothing. Doe the EVM use a real AM1707 or does it use an OMAP-L137?

real AM1707 CPU

The problem of "Uncompressing linux" hang is a common problem. There are many posts on this forum. The kernel may be booting up successfully. It's just not setting up the console for boot messages. It also might be crashing aborting before printing anything to the console. If you can telnet into it or ping the EVM, then the kernel booted successfully. Assumes your board has network and the kernel has network daemons started. Usual problems:

- U-Boot and the kernel have different mach type IDs. These IDs are hard-coded at compile time. This probaby is not your problem as the same u-boot-kernel pair boot successfully on the AM1707 EVM but not on the AM1705 custom board.

- The kernel does not support the particular silicon revision of the processor. The check uses hard-coded IDs in a JTAG table in da830.c. Newer variant numbers need to be added to older kernels for them boot properly. Last I checked, there is one OMAP-L137 version and the AM17xx has two versions. This is why I asked about the CPU.

- The serial ports got renamed in different versions of the kernel. The change involves ttySx (as in Serial) to ttyOx (as in Omap). Probably not your problem.

Try adding earlyprintk option to the bootargs. You might get an error message printed out before it goes silent. You might have to configure the kernel for early print .

I am guessing that the EVM had 64MB RAM but the custom board has 32MB. Perhaps your bootarg has specified 64MB. Just a guess. Are the u-boot environment variables the same on both boards?

Thanks,

this is all I tried to do, but problem remains the same.

I made the following:

1. machid from u-boot corresponds to the machid from kernel.

2. check silicon and revision id in the table from da830.c, It corresponds to the silicon and revision id from am1705 datasheet

3. tried to console arg set ttyS2 and ttyO2, no result

bootargs=console=ttyS2,115200n8 ip=off mem=32M

that you can still try to do and where to look?

Help me please

Did you try adding earlyprintk to the bootargs? Any extra messages? It's been while but I seem to remember that the line "Uncompressing Linux... done, booting the kernel." is from the mini-bootloader within the kernel uImage binary. So it has left u-boot.

yes,

I added option earlyprintk, but no result

if to lok the kernel src, and grep

grep -nrH -e "Uncompressing Linux" *

Documentation/ia64/serial.txt:85:    No kernel output after elilo prints "Uncompressing Linux... done":
Documentation/ia64/serial.txt:106:    Long pause (60+ seconds) between "Uncompressing Linux... done" and
Binary file arch/arm/boot/compressed/misc.o matches
Binary file arch/arm/boot/compressed/vmlinux matches
arch/arm/boot/compressed/misc.c:283:    putstr("Uncompressing Linux...");
arch/arm/boot/compressed/misc.c:297:    putstr("Uncompressing Linux...");
Binary file arch/arm/boot/zImage matches
arch/mn10300/Kconfig.debug:15:      decompressing Linux seeing "Uncompressing Linux... " and
arch/mn10300/boot/compressed/misc.c:18:/* display 'Uncompressing Linux... ' messages on ttyS0 or ttyS1 */
arch/mn10300/boot/compressed/misc.c:388:    kputs("Uncompressing Linux... ");
arch/alpha/boot/misc.c:168:/*    puts("Uncompressing Linux..."); */
arch/cris/boot/compressed/misc.c:388:    puts("Uncompressing Linux...\n");
arch/sh/boot/compressed/misc.c:144:    puts("Uncompressing Linux... ");
arch/h8300/boot/compressed/misc.c:178:    puts("Uncompressing Linux... ");
arch/mips/boot/compressed/decompress.c:108:    puts("Uncompressing Linux at load address ");

then we can say that the line Uncompressing Linux... done, booting the kernel. occur from kernel

Strictly speaking "Uncompressing Linux... done, booting the kernel." is from mini-bootloader or trampoliine program that uncompresses the kernel binary into RAM. But yeah, it's probably on the kernel when it stops. You might have to hook in the running system with a JTAG debugger to see exactly where it had stopped. Never done it myself. An alternative is to add the same "putstr()" calls after the "Uncompressing Linux..." call to trace the progress. Essentially printf debugging but remember that printf is not available.

I have a feeling it might be a SDRAM timing problem. Could be totally wrong as well. With custom boards based upon EVMS, the SDRAM tracks is about the only thing that can't be exactly duplicated. Maybe try relaxing the SDRAM timing parameters. A partial memory test from U-boot is possible. Tricky because U-Boot is in SDRAM at the time.

on my custom board is IS42S16160B  IC, but using 16 line data bus.

but on EVM1707 is two IS42S16160B IC( the same sdram ICs  ), and there is using 32 line data bus

may be a bug somewhere in the kernel source code associated with the configuration MMU, the width data bus, etc. everything related to sdram?!

please tell me what can I edit the source code, if we assume that the problem with sdram, width sdram data bus?

if simply test memory when u-boot ram, test mem is OK.

I believe the Linux kernel assumes the SDRAM is configured by one of the bootloaders. The kernel does not configure the SDRAM. It does configure the MMU. You should still get something out the serial port even if the MMU config fails.

The SDRAM config is in the bootloader that loads U-Boot. In TI naming convention, the first bootloader is called ROM Boot Loader or RBL. The second bootloader is called User Boot Loader or UBL. My experience is with the OMAP-L137 where there is a DSP and ARM UBL. In your case, I assume there is just the ARM UBL. In my case and probably yours, the SDRAM is configured in the ARM UBL. Probably in the same device.c file. The source should be somewhere in the your SDK. Did you program a UBL onto your custom board? If not, then U-Boot is the UBL and somewhere in U-Boot is a SDRAM config.

A SDRAM problem is a bit of improbable as U-Boot is in SDRAM and it is running. Perhaps U-Boot does not use the SDRAM as hard as Linux. I'm out of ideas.

on my custom board I`m not using UBL, just using u-boot that wrapped AISgen.

My problem is that I do not use the UBL?

I don't see anything wrong with not using the UBL. As long as you move whatever initialization the UBL was doing into U-Boot. In my case, U-Boot executed out of SDRAM, so SDRAM must be configured before hand. Not so sure in your case. Maybe your U-Boot executes from static RAM. I doubt the RBL is configuring SDRAM. Maybe the reset values in the DRAM controller is good enough to get going initially but not good enough when Linux starts up, ie. uses DMA and MMU.

Does the EVM use a UBL?

> Does the EVM use a UBL?

yes

I guess the obvious thing to try is to use the UBL on the custom board. It'll use up extra RAM and Flash but you can optimize it out later. The memory maps between EVM and custom board must different as well.

whether to use the last kernel source code from kernel.org?

I've seen others on this forum use the mainline stream from kernel.org. TI appears to have been prettry good about putting back TI specific changes to the mainline code. That said, I think that not all of the TI customizations made it to the mainline. I personally would not use the mainline code. TI's kernel is at www.arago-project.org. Look under "Main Arago git repositories" then "projects".

kernel starting, but suspening on calibrating.

U-Boot > printenv

bootdelay=5

baudrate=115200

bootfile="uImage"

ethaddr=00:16:76:4e:64:da

bootcmd=bootm 0xC0700000

bootargs=console=ttyS2,115200n8 earlyprintk mem=32M

stdin=serial

stdout=serial

stderr=serial

ver=U-Boot 2009.11 (Dec 09 2011 - 17:49:53)



Environment size: 234/16380 bytes

U-Boot > loadb

## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...

## Total Size      = 0x001eb588 = 2012552 Bytes

## Start Addr      = 0xC0700000

U-Boot > bootm

## Booting kernel from Legacy Image at c0700000 ...

   Image Name:   Linux-2.6.33-rc4

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    2012488 Bytes =  1.9 MB

   Load Address: c0008000

   Entry Point:  c0008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK



Starting kernel ...



Uncompressing Linux... done, booting the kernel.

Linux version 2.6.33-rc4 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 20

09q1-203) ) #2 PREEMPT Fri Dec 23 16:24:34 MSK 2011

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: DaVinci DA830/OMAP-L137/AM17xx EVM

Memory policy: ECC disabled, Data cache writethrough

DaVinci da830/omap-l137 rev2.0 variant 0x9

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128

Kernel command line: console=ttyS2,115200n8 earlyprintk mem=32M

bootconsole [earlycon0] enabled

PID hash table entries: 128 (order: -3, 512 bytes)

Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)

Memory: 32MB = 32MB total

Memory: 28268KB available (3736K code, 297K data, 140K init, 0K highmem)

SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Hierarchical RCU implementation.

NR_IRQS:245

Console: colour dummy device 80x30

Calibrating delay loop...

What changed to make it work? Did you change the SDRAM config? Note that the bootarg mem=32M will use 32 of 32M. Any of the TI software will try to obtain memory above Linux. On the EVM, Linux would get the lower 32M and TI stuff would grab the memory above that. You probably will have to lower the memory allocated to Linux. Don't know how much TI stuff needs.  Not familiar with the "Callibrating" hang.

> What changed to make it work?

no, just build the last linux kernel from kernel.org

>Did you change the SDRAM config?

no

> Note that the bootarg mem=32M will use 32 of 32M. Any of the TI software will try to obtain memory above Linux. On the EVM, Linux would get the lower 32M and TI stuff would grab the memory above that. You probably will have to lower the memory allocated to Linux.

What need doing to it? on EVM1707 64 MB, but mem set to bootargs = 32M

Never mind about allocating memory above Linux. That's for processors with a DSP. Forgot that the AM17xx does not have a DSP. My mistake.

Does your kernel from kernel.org work on the EVM? If it does, obviously there are HW differences that affecting Linux.

I'm confused about the kernel from kernel.org. Latest would be 2.6.39 or 3.0.x. The version 2.6.33-rc4 is the base for TI's 03.20.00.14 LSP. TI has release a newer version of the LSP, 03.21.00.04. It is based on linux 2.6.37 and u-boot 2010.12.

http://software-dl.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/DaVinci_03_21/index.html

It probably won't make your situation anymore stable but I think you should choose the newest kernel designed for your processor and stick with that one.

Norman,

Thanks!