From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Date: Fri, 29 Oct 2010 16:58:19 +0200 Subject: [U-Boot] Most ARM CPU's have buggy clear_bss? In-Reply-To: <4CCADF48.6060709@emk-elektronik.de> References: <4CC93C74.6050309@ahsoftware.de> <4CC94305.8060001@ahsoftware.de> <4CCA8AF0.3000201@ahsoftware.de> <4CCA91AD.3060806@free.fr> <4CCAB659.5010309@ahsoftware.de> <4CCAB954.5050506@free.fr> <4CCABEAF.40305@ahsoftware.de> <4CCACE26.8060104@free.fr> <4CCADC10.9010205@ahsoftware.de> <4CCADF48.6060709@emk-elektronik.de> Message-ID: <4CCAE10B.8050708@ahsoftware.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 29.10.2010 16:50, schrieb Reinhard Meyer: > Dear Alexander Holler, >> U-Boot 2010.12-rc1-00009-g27b7641-dirty (Oct 29 2010 - 15:58:59) >> Seagate-DockStar >> >> U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 >> SoC: Kirkwood 88F6281_A0 >> monitor len: 000A0300 >> ramsize: 08000000 >> TLB table at: 07ff0000 >> Top of RAM usable for U-Boot at: 07ff0000 >> Reserving 640k for U-Boot at: 07f4f000 >> Reserving 1152k for malloc() at: 07e2f000 >> Reserving 48 Bytes for Board Info at: 07e2efd0 >> Reserving 92 Bytes for Global Data at: 07e2ef74 >> New Stack Pointer is: 07e2ef70 >> RAM Configuration: >> Bank #0: 00000000 128 MiB >> Bank #1: 00000000 0 Bytes >> Bank #2: e7dfe27e 4 GiB > > Humm, should you not attend to the problems in the order they occur? > This can't be right, and might indicate a problem that is there already > before NAND is accessed? Or even cause subsequent problems? > If you declare having 4 RAM banks they should be properly initialized, > if they do not exist. > >> RAM Configuration: >> Bank #0: 00000000 128 MiB >> Bank #1: 00000000 0 Bytes >> Bank #2: 0197f8ff 3.3 GiB >> Bank #3: 0f0c0cab 3.5 GiB > > Same here. > > Best Regards, > Reinhard > Just to explain it: I had fixed that before and I've just checked out a clean branch and have applyed some patches which haven't included a fix for those wrong sizes which are displayed. But that doesn't change anything for the problem with the relocation (proofed before!). Regards, Alexander