From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Pandita, Vikram" <vikram.pandita@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.arm.linux.org.uk"
<linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Date: Thu, 27 Aug 2009 12:21:19 +0300 [thread overview]
Message-ID: <87hbvtfw8g.fsf@deeprootsystems.com> (raw)
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC35608702F9A44895@dbde02.ent.ti.com> (Vikram Pandita's message of "Thu\, 27 Aug 2009 08\:08\:14 +0530")
"Pandita, Vikram" <vikram.pandita@ti.com> writes:
>>Vikram Pandita wrote:
>>> This patch cleans up the DEBUG_LL infrastructure for omap boards.
>>
>>Thanks Vikram, this is indeed in need of some cleanup. But I have some
>>comments about the approach taken.
>>
>>This approach still doesn't solve one of the fundamental problems with
>>the current implementation. It prevents using a single kernel across
>>multiple boards. If we could drop the compile-time decision in favor of
>>a runtime one based on machine-type, we could use a single base
>>defconfig that would be able to be tested on all omap3 boards for example.
>>
>>For the zImage UART output (uncompress.h) there is a global variable
>>__machine_arch_type which could be used to check the board type and set
>>variable for UART base and shift. We do this on DaVinci.
>
> Could you give reference to this code on DaVinci?
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=blobdiff;f=arch/arm/mach-davinci/include/mach/uncompress.h;h=0f1f12b67875f86232c0e06e1a687a6d7f19b18a;hp=1e27475f9a2322f1a4f61e25fd1a1e5858e29fc2;hb=bb9647f44b091ebff17f400bb2a468c7e419f3ac;hpb=0dc6306a65f30c0483cfed9b3e8ee1eb3d093e84
>
> Yes this is doable, but the question is, how do we pass these variables to the kernel start:
> arch/arm/kernel/head.S
>
> First stage, arch/arm/boot/compressed/head.S gets the arch type -> shift/uart-addr. Fine.
> This stage ends with relocated code over righting the decompressor.
>
> Second stage, arch/arm/kernel/head.S now starts.
>
> I am not sure how to share the data from Stage 1 in this stage?
This is already taken care of.
The zImage boot passes the machine-type in a register, then
arch/arm/kernel/head.S uses that to decide which machine to start.
This is where the MACHINE_START/MACHINE_END macros come in to
define the machine-specific hooks called at boot time.
You should use one of the early machine hooks (probably .map_io)
to to set the UART base and shift for the board.
The catch is that between the start of the head.S code and the
mach->map_io hook, printascii() may be called and use the debug
macros to try to print out chars. Care must be taken that
if the UART is not yet known/defined, nothing is printed.
Kevin
next prev parent reply other threads:[~2009-08-27 9:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-21 17:55 [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup Vikram Pandita
2009-08-22 7:23 ` Shilimkar, Santosh
2009-08-22 7:57 ` Kevin Hilman
2009-08-24 14:14 ` Tony Lindgren
2009-08-27 2:38 ` Pandita, Vikram
2009-08-27 9:21 ` Kevin Hilman [this message]
2009-08-27 13:04 ` Pandita, Vikram
2009-08-27 13:29 ` Kevin Hilman
2009-09-16 19:11 ` Russell King - ARM Linux
2009-09-17 19:00 ` Pandita, Vikram
2009-09-17 19:47 ` Russell King - ARM Linux
2009-09-18 21:16 ` Pandita, Vikram
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=87hbvtfw8g.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-omap@vger.kernel.org \
--cc=vikram.pandita@ti.com \
/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