From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aneesh V <aneesh@ti.com>
Date: Sun, 03 Jul 2011 15:05:18 +0530
Subject: [U-Boot] [PATCH v2 22/22] omap: spl: add more debug traces
In-Reply-To: <20110615101829.3A5D2655C6@gemini.denx.de>
References: <1298893591-17636-1-git-send-email-aneesh@ti.com>
	<1305472900-4004-23-git-send-email-aneesh@ti.com>
	<20110515202139.EAB481491B06@gemini.denx.de>
	<4DF617C2.6070100@ti.com>
	<20110615101829.3A5D2655C6@gemini.denx.de>
Message-ID: <4E1037D6.4010900@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Wolfgang,

On Wednesday 15 June 2011 03:48 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>

[snip ..]

>> No. That wouldn't serve the purpose. I need two macros to distinguish
>> between the two cases.
>> 1. 'debug()' - can be used in all places at which console is guaranteed
>> to be initialized whether executed as part of U-Boot or SPL.
>> 2. 'spl_debug()' to be used at places where console is initialized for
>> SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for
>> U-Boot.
>
> You see - this distinction is becoming a mess.  Let's get rid of this
> and use common code for both cases.

I replaced spl_debug() with debug() now. I moved sdram_init() out of
lowlevel_init() for u-boot so that console is available by the time
sdram_init() runs.

However, clock init needs to remain in lowlevel_init() and I still feel
that some debug traces from this module will be a good debugging tool
for SPL, so I retained the traces and added something like this in
arch/arm/cpu/armv7/omap4/clocks.c:


/*
  * printing to console doesn't work unless
  * this code is executed from SPL
  */
#ifndef CONFIG_PRELOADER
#define printf(fmt, args...)
#define puts(s)
#endif

Is that fine?

best regards,
Aneesh