All of lore.kernel.org
 help / color / mirror / Atom feed
From: Angelo Dureghello <angelo70@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [HELP] coldfire, bss.variable offset greater than __bss_end
Date: Sat, 10 Sep 2011 17:51:02 +0200	[thread overview]
Message-ID: <4E6B8766.1040708@gmail.com> (raw)

Hi all,

i reply just to close the thread and to help each other that can have similar issues, this since i have seen other boards that can have the same issue.

The issue was related to my custom board, and more properly was that the linker added some other .bss.* variables after __bss_end__ , that of course u-boot was not relocating into sdram. Error was in my board-related u-boot.lds:

WRONG

  __bss_start = .;
  .bss (NOLOAD)       :
  {
   _sbss = .;
   *(.sbss)
   *(.bss)  <----
   *(COMMON)
   . = ALIGN(4);
   _ebss = .;
  }

CORRECT

  __bss_start = .;
  .bss (NOLOAD)       :
  {
   _sbss = .;
   *(.sbss*)
   *(.bss*)
   *(COMMON)
   . = ALIGN(4);
   _ebss = .;
  }

regards,
angelo


-------- Original Message --------
Subject: [HELP] coldfire, bss.variable offset greater than __bss_end
Date: Sat, 10 Sep 2011 00:41:58 +0200
From: Angelo Dureghello <angelo70@gmail.com>
To: U-Boot at lists.denx.de <U-Boot@lists.denx.de>

Hi all,

after a recent update and compiling u-boot, bootloader get locked trying to set a global variable, just after sdram relocation.

Exactly, the program lock here:


1529  void mem_malloc_init(ulong start, ulong size)
1530  {
1531	mem_malloc_start = start;   <<<---program paralize here



Tracing the variable offset in memory, i have seen this variable is located a little bit outside (higher address) of the total 16M SDRAM memory size.

Investigating further, in the map file, the issue seems to be that u-boot assign a memory space that is:

len = (ulong)&__bss_end__ - CONFIG_SYS_MONITOR_BASE;

But from the map file the variable seems to have an offset greater than __bss_end :



.bss.mem_malloc_start
                0xffc159c8        0x4
 .bss.mem_malloc_start
                0xffc159c8        0x4 common/libcommon.o
                0xffc159c8                mem_malloc_start

.....

.bss            0xffc13e00     0x1544
                0xffc13e00                _sbss = .
 *(.sbss)
 *(.bss)
 *(COMMON)
 COMMON         0xffc13e00        0x4 arch/m68k/lib/libm68k.o
                0xffc13e00                monitor_flash_len


u-boot.lds has been checked many times, i don't see any issue on it.

I am using this compiler:

m68k-elf-gcc --version
m68k-elf-gcc (GCC) 4.2.4
Copyright (C) 2007 Free Software Foundation, Inc.

Any help is really appreciated.

regards,
angelo

             reply	other threads:[~2011-09-10 15:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-10 15:51 Angelo Dureghello [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-09-09 22:41 [U-Boot] [HELP] coldfire, bss.variable offset greater than __bss_end Angelo Dureghello

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=4E6B8766.1040708@gmail.com \
    --to=angelo70@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.