Subject: Bug#494010: Source for dsp56k firmware
Newsgroups: gmane.linux.debian.devel.bugs.rc
Date: 2008-10-15 17:49:19 GMT (1 year, 16 weeks, 5 days, 1 hour and 52 minutes ago)
On Wed, Oct 15, 2008 at 06:12:23PM +0200, Robert Millan wrote: > On Wed, Oct 15, 2008 at 03:16:56AM +0100, Ben Hutchings wrote: > > It's for a Motorola 56000 (aka DSP56000 or DSP56K) processor, which is a > > different architecture but maybe with some similarities. I doubt we > > have any of the necessary tools but the code is short enough to hand- > > assemble. > > I found an assembler, "a56" (see http://www.zdomain.com/a56.html), which seems > to be DFSG-free (BSD-style license). I'll see about packaging it. Gah, there's a bit more to this: - First I had to run "frodos" on bootstrap.asm to cleanup the CRLF. - Attached patch fixes a few errors spit by a56. I think my other two fixes are correct, but I have no idea what the '<' / '>' candy is supposed to do (hints?). - Resulting offsets doen't match with the blob. I still haven't figured out how are program code offsets mapped to the output file, but some parts don't match. For example, the blob has a jump (0C 00 40) to 0x40 (and so does a56 output, at offset 0x0 in both cases), but then code from the blob continues at 0xc0, unlike code from a56 which continues at 0x40. Is there some trick to this? Attached as well is tobin.c, a small parser I've written to test this (it reads a56 output and writes it to output file in binary form). Also attaching the blob in binary form for convenience. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."