From: Rob Landley <rob@landley.net>
To: zhaoyilong <registcn@gmail.com>
Cc: linux- embedded <linux-embedded@vger.kernel.org>
Subject: Re: How to use DEBUG macros in compressed/head.S
Date: Wed, 16 Jan 2013 11:05:33 -0600 [thread overview]
Message-ID: <1358355933.32505.38@driftwood> (raw)
In-Reply-To: <94B6F8A1EDC14A8CB9308D5F65F19892@VIU9IM6TKCWEEDX> (from registcn@gmail.com on Wed Jan 16 02:17:39 2013)
On 01/16/2013 02:17:39 AM, zhaoyilong wrote:
> When I open the macro DEBUG in the front of file
> arch/arm/boot/decompressed/head.S,the kernel runs and stops
> at"Uncompressing
> Linux... done, booting the kernel."
No, that's just the last thing it output.
I seldom find other people's debug code useful. I stick a printf()
variant in the code at a place I want to see what it's doing, and then
I know what the output means. I only enable their debug code if I'm
sending the output to the person who wrote said debug code. (There are
exceptions, but they're exceptions to a useful rule of thumb.)
At this level, you can do direct writes to the serial chip ala:
http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
Note that's for qemu, which pauses when it gets a port write. For real
hardware you need to check the status bit before sending the next
character, basically spinning on a port read until the relevant bit
gets set/cleared to indicate the hardware's done with the last thing
you sent it. I don't remember the check off the top of my head (last
time I needed it I dug it out of the uboot source), but if you're just
debugging you can do a delay loop between each write. (This is assuming
your serial port is already set to the right speed, which it had to be
to spit out the above message. Presumably the bootloader did it for
you.)
(And this is assuming your board layout has an 8250/16550a UART variant
mapped at a knowable address, which basically they all do because it's
dirt simple and the patents expired years ago. They get weird and
bespoke about setting buffer sizes but you don't really have to care at
this level.)
Most likely you can find whatever spit out the text you _did_ see, and
copy it to produce more text from places in the code you'd like
visibility into.
Rob
prev parent reply other threads:[~2013-01-16 17:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 8:17 How to use DEBUG macros in compressed/head.S zhaoyilong
2013-01-16 10:30 ` Baurzhan Ismagulov
2013-01-16 17:05 ` Rob Landley [this message]
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=1358355933.32505.38@driftwood \
--to=rob@landley.net \
--cc=linux-embedded@vger.kernel.org \
--cc=registcn@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).