public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <heiko.schocher@invitel.hu>
To: u-boot@lists.denx.de
Subject: [U-Boot] Most ARM CPU's have buggy clear_bss?
Date: Thu, 28 Oct 2010 07:50:56 +0200	[thread overview]
Message-ID: <4CC90F40.4020405@invitel.hu> (raw)
In-Reply-To: <4CC86B67.3000701@gmail.com>

Hello Darius,

Darius Augulis wrote:
> On 10/27/2010 06:12 PM, Eric Cooper wrote:
>> On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
>>> Maybe it could be reason why I'm facing strange problem, when after
>>> relocating uboot with nand_spl no one command is not working.  I
>>> debugged that command table is empty.
>> Maybe this is the same problem I reported here (commands not found):
>> http://lists.denx.de/pipermail/u-boot/2010-October/080198.html
>>
> 
> looks similar, but not exactly the same. Mine output:
> 
> U-Boot 2010.09-00560-g5b4d583-dirty (Oct 27 2010 - 21:00:13) for MINI6410
> 
> U-Boot code: 57E00000 -> 57E2BDE4  BSS: -> 57E31680
> 
> CPU:     S3C6400 at 532MHz
>           Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz (SYNC Mode)
> Board:   MINI6410
> monitor len: 00031680
> ramsize: 08000000
> TLB table at: 57ff0000
> Top of RAM usable for U-Boot at: 57ff0000
> Reserving 197k for U-Boot at: 57fbe000
> Reserving 1280k for malloc() at: 57e7e000
> Reserving 24 Bytes for Board Info at: 57e7dfe8
> Reserving 92 Bytes for Global Data at: 57e7df8c
> New Stack Pointer is: 57e7df88
> RAM Configuration:
> Bank #0: 50000000 128 MiB
> relocation Offset is: 001be000
> monitor flash len: 0002BDE4
> Now running in RAM - U-Boot at: 57fbe000
> NAND:  raise: Signal # 8 caught
> raise: Signal # 8 caught
> raise: Signal # 8 caught

This looks suspect to me. Seems to me some early init
(pin setup? clocks?) is not OK. If you have early inits,
you must do that now in board_early_init_f() (and you
have to define CONFIG_BOARD_EARLY_INIT_F to enable this
feature)

> 256 MiB
> Using default environment
> 
> Destroy Hash Table: 57e31568 table = (null)
> Create Hash Table: N=79
> INSERT: table 57e31568, filled 1/79 rv 57e7f42c ==> name="bootargs" 
> value="console=ttySAC,115200"
> INSERT: table 57e31568, filled 2/79 rv 57e7f348 ==> name="bootcmd" 
> value="nand read 0x50018000 0x60000 0x1c0000;bootm 0x50018000"
> INSERT: table 57e31568, filled 3/79 rv 57e7f438 ==> name="bootdelay" 
> value="3"
> INSERT: table 57e31568, filled 4/79 rv 57e7f378 ==> name="baudrate" 
> value="115200"
> INSERT: free(data = 57e7f2a0)
> INSERT: done
> In:    serial
> Out:   serial
> Err:   serial
> Net:   dm9000
> ### main_loop entered: bootdelay=3
> 
> ### main_loop: bootcmd="nand read 0x50018000 0x60000 0x1c0000;bootm 
> 0x50018000"
> Hit any key to stop autoboot:  0
> MINI6410 # help
> Unknown command 'help' - try 'help'
> MINI6410 #
> 
> I'm doing support for new board, so there could be some bugs in its 
> config. But I still thinking that clear_bss code is buggy, because uboot 
> reboots is DEBUG if defined and following simple patch isn't applied:

Maybe you look in the tx25 board port. This board boots also
with nand_spl (but it is arm926ejs based).

Note: CONFIG_SKIP_RELOCATE_UBOOT seems to get obsolete to me.

What worked for me on the tx25 board was, that I set
TEXT_BASE = relocation address, so I got relocation offset = 0
and code don;t gets copied twice, but this addr is not constant
(code size changes, maybe pram features ...) so I dropped this
approach for this board.

bye,
Heiko

  reply	other threads:[~2010-10-28  5:50 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27  7:26 [U-Boot] Most ARM CPU's have buggy clear_bss? Darius Augulis
2010-10-27  8:01 ` Sughosh Ganu
2010-10-27  8:22   ` Darius Augulis
2010-10-27  8:54     ` Sughosh Ganu
2010-10-27  8:58       ` Darius Augulis
2010-10-27  9:09         ` Sughosh Ganu
2010-10-27 10:10           ` Darius Augulis
2010-10-27 10:40             ` Wolfgang Denk
2010-10-27 10:59               ` Darius Augulis
2010-10-27 11:41                 ` Wolfgang Denk
2010-10-27 15:12 ` Eric Cooper
2010-10-27 18:11   ` Darius Augulis
2010-10-28  5:50     ` Heiko Schocher [this message]
2010-10-28  6:09       ` Reinhard Meyer
2010-10-28  6:17         ` Heiko Schocher
2010-10-28  6:20           ` Reinhard Meyer
2010-10-28  6:23             ` Reinhard Meyer
2010-10-28  6:35               ` Heiko Schocher
2010-10-28  6:14 ` Heiko Schocher
2010-10-28  6:36   ` Reinhard Meyer
2010-10-28  6:56     ` Darius Augulis
2010-10-28  8:36       ` Wolfgang Denk
2010-10-28  8:31     ` Wolfgang Denk
2010-10-28  8:39   ` Wolfgang Denk
2010-10-28  8:53     ` Heiko Schocher
2010-10-28 10:23     ` Alexander Holler
2010-10-28 11:16       ` Reinhard Meyer
2010-10-28 11:38         ` Wolfgang Denk
2010-10-28 11:55           ` Reinhard Meyer
2010-10-29  9:29           ` Albert ARIBAUD
2010-10-28 11:46         ` [U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used? Alexander Holler
2010-10-29  9:32           ` Albert ARIBAUD
2010-10-29 11:32             ` Alexander Holler
2010-10-29 11:43               ` Albert ARIBAUD
2010-10-29 11:48                 ` Wolfgang Denk
2010-10-28  9:03 ` [U-Boot] Most ARM CPU's have buggy clear_bss? Alexander Holler
2010-10-28  9:31   ` Alexander Holler
2010-10-29  8:50     ` Alexander Holler
2010-10-29  9:19       ` Albert ARIBAUD
2010-10-29 11:56         ` Alexander Holler
2010-10-29 12:08           ` Albert ARIBAUD
2010-10-29 12:31             ` Alexander Holler
2010-10-29 13:37               ` Albert ARIBAUD
2010-10-29 13:50                 ` Alexander Holler
2010-10-29 14:04                   ` Albert ARIBAUD
2010-10-29 14:37                 ` Alexander Holler
2010-10-29 14:44                   ` Wolfgang Denk
2010-10-29 14:50                     ` Alexander Holler
2010-10-29 14:50                   ` Reinhard Meyer
2010-10-29 14:58                     ` Alexander Holler
2010-10-29 14:54                   ` Albert ARIBAUD
2010-10-29 15:05                     ` Alexander Holler
2010-10-29 15:23                       ` Albert ARIBAUD
2010-10-29 15:32                         ` Alexander Holler
2010-10-29 15:38                           ` Albert ARIBAUD
2010-10-29 16:56                             ` Alexander Holler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CC90F40.4020405@invitel.hu \
    --to=heiko.schocher@invitel.hu \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox