[U-Boot] disassembler ?

[U-Boot] disassembler ?

[Brad Walker]

I noticed there is no support for a disassembler except for BedBug.

I am working on a new processor and board for that processor. I'm in need
of a disassembler for this work.

I was thinking about adding a cmd_dis.c file as a stub and make the
implementation exist in board/..

Is this the right way to go as we are willing to release our code back to
the community once it is completed. Ideas/comments about this are
appreciated.

-brad w.

[U-Boot] disassembler ?

[Albert ARIBAUD]

Hi Brad,

On Thu, 16 May 2013 10:45:47 -0600, Brad Walker <bwalker@musings.com>
wrote:

> I noticed there is no support for a disassembler except for BedBug.
>
> I am working on a new processor and board for that processor. I'm in need
> of a disassembler for this work.
> 
> I was thinking about adding a cmd_dis.c file as a stub and make the
> implementation exist in board/..
> 
> Is this the right way to go as we are willing to release our code back to
> the community once it is completed. Ideas/comments about this are
> appreciated.

There is little too no point in having a disassembler command in U-Boot,
when one can usually talk to the target with a debugging probe that
will work with gdb, and thus allow using gdd's own disassembler.

(also, out of the target, objdump can disassemble an ELF binary)

The best location IMO for putting the disassembler is by adding support
for your new processor to gcc/gdb/objdump so that you have it not only
for U-Boot but for any other code you care to build for this processor.

> -brad w.

Amicalement,
-- 
Albert.

[U-Boot] disassembler ?

[Wolfgang Denk]

Dear Brad Walker,

In message <CAPKZHbVOpoLNHAsjfwyEi9783zgYbfNuf9_GZ=AVuXTmEwSy_g@mail.gmail.com> you wrote:
>
> I am working on a new processor and board for that processor. I'm in need
> of a disassembler for this work.

And why exactly do you need that on the target?

Why cannot you just use objdump ?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.

[U-Boot] disassembler ?

[Brad Walker]

Sorry for being delayed on getting back to you on this. Work issues took
hold.

There were several good questions.

Let me give you some background.

I am working at a start-up. We are building a new processor and system for
that new processor. So we have hardware work and software work to get
through.

Part of my reasoning in asking the question about a disassembler is becuase
there is  a reference to BedBug in the manual.
http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As
well as, the BedBug debugger is in the source code.

So I'm trying to understand at a high level if I can utilize this work to
help me. Or should I just go and implement this independently.

Why not just use JTAG? We are doing new processor design, so it's not
defined if the system will even have a JTAG interface. There are lots of
systems that do not have a JTAG interface.

Why not use use objdump? We are in the process of porting binutils, so I
currently don't have an objdump to use. I do have a manual disassembly
routine that we created in h/w design to help us. But, until binutils has
been ported, there is no objdump.

I think the big issue that is confusing to me is why is BedBug still in
U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy
to do the work and contribute it back to the group. But, if not, then I'll
just go ahead implement the work independently.

Hopefully, this makes sense. Feel free to ask questions.

-brad w.



On Thu, May 16, 2013 at 4:15 PM, Wolfgang Denk <wd@denx.de> wrote:

> Dear Brad Walker,
>
> In message <CAPKZHbVOpoLNHAsjfwyEi9783zgYbfNuf9_GZ=
> AVuXTmEwSy_g at mail.gmail.com> you wrote:
> >
> > I am working on a new processor and board for that processor. I'm in need
> > of a disassembler for this work.
>
> And why exactly do you need that on the target?
>
> Why cannot you just use objdump ?
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> We, the unwilling, led by the unknowing, are doing the impossible for
> the ungrateful. We have done so much, for so long, with so little, we
> are now qualified to do anything with nothing.
>

[U-Boot] disassembler ?

[Albert ARIBAUD]

Hi Brad,

On Thu, 23 May 2013 11:13:53 -0600, Brad Walker <bwalker@musings.com>
wrote:

> Sorry for being delayed on getting back to you on this. Work issues took
> hold.
> 
> There were several good questions.
> 
> Let me give you some background.
> 
> I am working at a start-up. We are building a new processor and system for
> that new processor. So we have hardware work and software work to get
> through.
> 
> Part of my reasoning in asking the question about a disassembler is becuase
> there is  a reference to BedBug in the manual.
> http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As
> well as, the BedBug debugger is in the source code.
> 
> So I'm trying to understand at a high level if I can utilize this work to
> help me. Or should I just go and implement this independently.
> 
> Why not just use JTAG? We are doing new processor design, so it's not
> defined if the system will even have a JTAG interface. There are lots of
> systems that do not have a JTAG interface.
> 
> Why not use use objdump? We are in the process of porting binutils, so I
> currently don't have an objdump to use. I do have a manual disassembly
> routine that we created in h/w design to help us. But, until binutils has
> been ported, there is no objdump.
> 
> I think the big issue that is confusing to me is why is BedBug still in
> U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy
> to do the work and contribute it back to the group. But, if not, then I'll
> just go ahead implement the work independently.
> 
> Hopefully, this makes sense. Feel free to ask questions.

The way I understand your project, I wonder why you want to disassemble
code at all: if you manage to get U-Boot running on your target with
BedBug support for your CPU enabled, this means you have a working
gcc+binutils, which in turn means you have a toolchain, including an
assembler, that works well enough for bedbug to become pointless.

Compare the bedbug and objdump/gdb options: on the one hand you get a
crude debugger and disassembler that will only run from U-Boot and will
be practically useless for debugging say a Linux kernel or U-Boot
itself; and on the other hand, with objdump you get a disassembler that
will work on just about any binary, and with gdb, you get a debugger
that will debug anything from U-boot to userland apps.

Also, I *very* strongly suggest that you integrate *some* debugging
interface, based on *some* industry standard. Seeing as you're working
on a brand new, untested so far, silicon, such a debugging interface is
an absolute must IMO.

> -brad w.

Amicalement,
-- 
Albert.

[U-Boot] disassembler ?

[Peter Barada]

On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
> Also, I *very* strongly suggest that you integrate *some* debugging
> interface, based on *some* industry standard. Seeing as you're working
> on a brand new, untested so far, silicon, such a debugging interface
> is an absolute must IMO.
Ditto here.

JTAG (or some other industry debugging standard) allows attaching mature
tools (like an Abatron BDI or some such) to not only help verify the
state, but develop/debug the code you're writing.  Without such you'll
only be able to do a postmortem and inspect memory after the
code/processor crash - a much more laborious process...

-- 
Peter Barada
peter.barada at logicpd.com

[U-Boot] disassembler ?

[Albert ARIBAUD]

Hi Peter,

On Thu, 23 May 2013 15:08:24 -0400, Peter Barada
<peter.barada@logicpd.com> wrote:

> On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
> > Also, I *very* strongly suggest that you integrate *some* debugging
> > interface, based on *some* industry standard. Seeing as you're working
> > on a brand new, untested so far, silicon, such a debugging interface
> > is an absolute must IMO.
> Ditto here.
> 
> JTAG (or some other industry debugging standard) allows attaching mature
> tools (like an Abatron BDI or some such) to not only help verify the
> state, but develop/debug the code you're writing.  Without such you'll
> only be able to do a postmortem and inspect memory after the
> code/processor crash - a much more laborious process...

One won't even be able to do that, at least not if the inspection is
done using Bedbug within U-Boot since launching U-boot will, in itself,
overwrite some of the memory -- and Murphy guarantees that the
overwritten memory will include the areas needed for a successful
postmortem.

Amicalement,
-- 
Albert.

[U-Boot] disassembler ?

[Peter Barada]

On 05/23/2013 03:49 PM, Albert ARIBAUD wrote:
> Hi Peter,
>
> On Thu, 23 May 2013 15:08:24 -0400, Peter Barada
> <peter.barada@logicpd.com> wrote:
>
>> On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
>>> Also, I *very* strongly suggest that you integrate *some* debugging
>>> interface, based on *some* industry standard. Seeing as you're working
>>> on a brand new, untested so far, silicon, such a debugging interface
>>> is an absolute must IMO.
>> Ditto here.
>>
>> JTAG (or some other industry debugging standard) allows attaching mature
>> tools (like an Abatron BDI or some such) to not only help verify the
>> state, but develop/debug the code you're writing.  Without such you'll
>> only be able to do a postmortem and inspect memory after the
>> code/processor crash - a much more laborious process...
> One won't even be able to do that, at least not if the inspection is
> done using Bedbug within U-Boot since launching U-boot will, in itself,
> overwrite some of the memory -- and Murphy guarantees that the
> overwritten memory will include the areas needed for a successful
> postmortem.
>
>
If one was lucky maybe.  But who builds schedules around luck?  And yes,
Murphy's a mother...

I was assuming that through some black magic they could get into Bedbug
on reset and use it to inspect memory.  Of course this assumes that
Bedbug and u-boot don't collide, u-boot doesn't try to relocate itself
(or scribble over memory), all of which is extra development that a
JTAG[1] attached debugger would preclude.

A JTAG debugger would allow you to load code directly into memory and
then step through the processor initialization(or supply instructions on
the fly!), low-level startup development that everyone does on a new
processor.  Also by stepping you can see where/when the processor is
about to go off into the weeds many, many, many instructions _before_ it
munches any hope of postmortem debugging.  From experience bringing up
boards w/o JTAG is not only tedious but unpredictable and takes a
loooong time - the extra cost/effort of integrating JTAG (especially
since this is a spanking new processor!) is more than justified by it
reducing both total development time and overall schedule risk...

[1] I use JTAG to mean any industry standard hardware debug/access
method that allows arbitrary execution and inspection/modification of
registers/memory...


-- 
Peter Barada
peter.barada at logicpd.com

[U-Boot] disassembler ?

[Wolfgang Denk]

Dear Brad Walker,

In message <CAPKZHbU1wKxJZ82O9v54Lct482o7MfcN4Yq_WniwL-TB8_-cGg@mail.gmail.com> you wrote:
>
> Why not just use JTAG? We are doing new processor design, so it's not
> defined if the system will even have a JTAG interface. There are lots of
> systems that do not have a JTAG interface.

I have no information what the target for your new processor might be;
there is such systems that go to basically a single big customer / a
single, highly specific use case, and there are those that are
intended for general use - the more use cases the better.  If you want
to make your system easy to use for a big grouyp of people, then make
sure that standard debug tools work.  Include JTAG, and make sure it
works with standard tools like the Abatron BDI2000/3000, Lauterbach
Trace32 and OpenOCD etc.

> Why not use use objdump? We are in the process of porting binutils, so I
> currently don't have an objdump to use. I do have a manual disassembly
> routine that we created in h/w design to help us. But, until binutils has
> been ported, there is no objdump.

Well, without a working binut=ils you cannot build U-Boot anyway, so
you probably have to wait for that.

> I think the big issue that is confusing to me is why is BedBug still in
> U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy

BedBug is strill there, because it was useful for some (at some point
of time), and it does not hurt to have it.  I think the actual number
of users is epsilon.

> to do the work and contribute it back to the group. But, if not, then I'll
> just go ahead implement the work independently.

I'd recommend to save the efforts, and rather help the guys who are
working on binutils.  This is probably better invested time, then.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_