[U-Boot] disassembler ?

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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.