Hi Brad, On Thu, 23 May 2013 11:13:53 -0600, Brad Walker <bwal...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
