How to use DEBUG macros in compressed/head.S

How to use DEBUG macros in compressed/head.S

[zhaoyilong]

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."
CONFIG_DEBUG_ICEDCC is closed by default, so I am sure  the code runs tothe
following branch:
...........
...........
...........
.macro kputc,val
mov r0, \val
bl putc
.endm

.macro kphex,val,len
mov r0, \val
mov r1, #\len
bl phex
.endm

.macro debug_reloc_start
#ifdef DEBUG
kputc #'\n'
kphex r6, 8 /* processor id */
kputc #':'
kphex r7, 8 /* architecture id */
...........
...........
...........

Problem is happened in a context like this:

    I have a board use cpu S5PV210,and an ok kernel provide by the factory
anda  kernel download from kernel.org which carshed after printing "starting
kernel..." to dnw.
    To debug this,I want to test the macro kputc provided in this file——
using ok kernel.
I add a line "kputc #'a' " after the tag ".text", then make error says
"undefined reference to `putc' ",it seems that compiler cant find "putc"
used in
the definition of macro “kputc”.
    This is an ok kernel,so I cant say the serial port is not open——can
this mean "putc" is defined already?.

So I open DEBUG hoping to see debugging info by kernel itself,but it stops
at"Uncompressing Linux... done, booting the kernel."
Opening DEBUG will lead to the call of “kputc #'\n' ” in the code above
which will also call putc!

Here,my questions comes:

1?Why the error "  undefined reference to `putc'  " disappeared?
2?Why it stops at"Uncompressing Linux... done, booting the kernel."?
3?Can this error ( undefined reference to `putc'  ) mean the serial port is
not open? Where is it defined ?
Is it refer to the C function or just an assembly macro?

Re: How to use DEBUG macros in compressed/head.S

[Baurzhan Ismagulov]

Hello zhaoyilong,

I do get your mails.

On Wed, Jan 16, 2013 at 04:17:39PM +0800, zhaoyilong wrote:
> CONFIG_DEBUG_ICEDCC is closed by default, so I am sure  the code runs tothe
> following branch:
...
> .macro kputc,val
...
> .macro kphex,val,len
...
> .macro debug_reloc_start
...

What do you mean by "branch"? Those are macro definitions that are
expanded inline by the assembler.


>     To debug this,I want to test the macro kputc provided in this file——
> using ok kernel.

So you have a vendor kernel that works on your board? That is good.


> I add a line "kputc #'a' " after the tag ".text", then make error says
> "undefined reference to `putc' ",it seems that compiler cant find "putc"
> used in
> the definition of macro “kputc”.
>     This is an ok kernel,so I cant say the serial port is not open——can
> this mean "putc" is defined already?.

We don't have your vendor's kernel, so no one except your vendor can
tell. Possibly DEBUG support for head.S is broken in that tree.


> 1?Why the error "  undefined reference to `putc'  " disappeared?

What do you mean by "disappeared"? Do I understand correctly, the vendor
kernel didn't build with DEBUG enabled, and still doesn't? And the
mainline kernel does build? If so, the vendor kernel is broken w.r.t.
DEBUG in head.S.


> 2?Why it stops at"Uncompressing Linux... done, booting the kernel."?

Often it's an exception somewhere. It may be an exception in kputc. So
it's important to know whether kputc works in a working kernel, which
you can't test since the vendor kernel doesn't build with DEBUG in
head.S.


> 3?Can this error ( undefined reference to `putc'  ) mean the serial port is
> not open? Where is it defined ?
> Is it refer to the C function or just an assembly macro?

Since it's called from the assembly code, I'd assume it's a macro. Grep
for it in the mainline kernel and see whether it exists at the same
location in the vendor kernel.


That said, in my experience, the problem start later. So if your goal is
to port the board support code from the vendor kernel to the mainline
one (which is a good idea), start with it: Copy the board support file
to the mainline kernel and run that kernel. If it doesn't work, there is
a couple of things to check, such as machine id and serial console. If
you can get a JTAG debugger (e.g., an OpenOCD one), it would help.


With kind regards,
Baurzhan.

Re: How to use DEBUG macros in compressed/head.S

[Rob Landley]

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