Bug#494010: Source for dsp56k firmware
On Thu, Oct 16, 2008 at 04:50:11PM +0200, Robert Millan wrote: Ok, fixed that. I got a 100% code match now. The only remaining question is what's the deal with this section that's supposed to start at 0x7ea9 but actually starts at 0x4f (0xed in the file). My code adds a workaround for that: if (offset 0x7000) offset -= 0x7e5a; It seems the whole point is to avoid generating a huge file. Address 0x7ea9 needs to be used for some reason, so the code uses org 7ea9 to generate absolute offsets in code using that address, but the code itself is saved at 0x4f. Then the copy routine reallocates that to 7ea9 in runtime. I can live without knowing why the code needs to run in that address; but I'm still puzzled by how is the code supposed to tell the assembler that the 0x7ea9 chunk really should be saved to 0x4f. We can't remove my ad-hoc hack without knowing that -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: ITP: a52 -- Motorola DSP56001 assembler (Re: Bug#494010: Source for dsp56k firmware)
clone 494010 -1 retitle -1 ITP: a52 -- Motorola DSP56001 assembler block 494010 by -1 reassign -1 wnpp thanks *** debian-devel: Please drop #494010 from CC if your reply is only relevant to my ITP and not directly to that bug, thanks!*** * Package name: a52 Version : 1.3 Upstream Author : Quinn C. Jensen * URL : http://www.zdomain.com/a56.html * License : BSDish Programming Lang: C, Yacc, Bison Description : Motorola DSP56001 assembler a52 is an assembler for the Motorola DSP56001 family of microcontrollers. It is capable of compiling the firmware used in Linux' dsp56k.c driver. -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: Source for dsp56k firmware
On Fri, Oct 17, 2008 at 08:45:06AM +0200, Robert Millan wrote: I can live without knowing why the code needs to run in that address; but I'm still puzzled by how is the code supposed to tell the assembler that the 0x7ea9 chunk really should be saved to 0x4f. We can't remove my ad-hoc hack without knowing that Ok I just found a solution that is much more reasonable. When the offset exceeds 0x7000, we just add 1 word (3 bytes) to the previous one. It's still an ugly hack, but I believe it's not ad-hoc to this particular code. And by far it's much better than what we have now :-P -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: Source for dsp56k firmware
On Thu, Oct 16, 2008 at 12:32:15AM +0100, Ben Hutchings wrote:
- 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?).
According to the assembler reference manual
http://www.freescale.com/files/dsp/doc/ref_manual/DSPASMRM.pdf they mean:
- I/O short addressing mode force operator
- Short addressing mode force operator
- Long addressing mode force operator
Thanks. This seems to be a non-issue (resulting code is the same, indicating
a56 already makes the same assumptions).
- 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?
It's a 24-bit processor and uses word-addressing, not byte-addressing.
Ok, fixed that. I got a 100% code match now. The only remaining question is
what's the deal with this section that's supposed to start at 0x7ea9 but
actually starts at 0x4f (0xed in the file). My code adds a workaround for
that:
if (offset 0x7000)
offset -= 0x7e5a;
which is really nasty. Anyone knows better?
--
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.
- Remove '' and '' candy (they specify explicit addressing modes,
which a56 don't grok, but uses follows implicitly anyway).
- Replace 'move' with 'movem' when accessing program memory.
- Rename a few labels to avoid duplicates (which a56 can't handle).
--- ../bootstrap.asm.old 2008-10-15 18:22:56.0 +0200
+++ ../bootstrap.asm 2008-10-16 15:53:29.0 +0200
@@ -51,19 +51,19 @@
; Copy DSP program control
move#real,r0
move#upload,r1
-do #upload_end-upload,_copy
-moveP:(r0)+,x0
-movex0,P:(r1)+
-_copy movep #4,X:M_HCR
-movep #$c00,X:M_IPR
+do #upload_end-upload,_copy
+movemP:(r0)+,x0
+movemx0,P:(r1)+
+_copy movep #4,X:M_HCR
+movep #$c00,X:M_IPR
and #$fe,mr
jmp upload
real
org P:$7ea9
upload
-movep #1,X:M_PBC
-movep #0,X:M_BCR
+movep #1,X:M_PBC
+movep #0,X:M_BCR
nextjclr#0,X:M_HSR,*
movep X:M_HRX,A
@@ -81,18 +81,18 @@
cmp x0,A
jeq load_Y
-load_P do y0,_load
+load_P do y0,_load_P
jclr#0,X:M_HSR,*
movep X:M_HRX,P:(r0)+
-_load jmp next
-load_X do y0,_load
+_load_P jmp next
+load_X do y0,_load_X
jclr#0,X:M_HSR,*
movep X:M_HRX,X:(r0)+
-_load jmp next
-load_Y do y0,_load
+_load_X jmp next
+load_Y do y0,_load_Y
jclr#0,X:M_HSR,*
movep X:M_HRX,Y:(r0)+
-_load jmp next
+_load_Y jmp next
upload_end
end
#include stdlib.h
#include stdint.h
#include stdio.h
#include fcntl.h
#include sys/types.h
main (int argc, char *argv[])
{
unsigned int offset;
unsigned int native_value;
int fd;
uint8_t value[3];
char type;
char *line = NULL;
size_t zero = 0;
if (argc != 2)
{
fprintf (stderr, Usage: %s output input\n, argv[0]);
exit (1);
}
fd = open (argv[1], O_WRONLY | O_CREAT | O_TRUNC, 0644);
while (getline (line, zero, stdin) != -1)
{
sscanf (line, %c , type);
if (type != 'P')
continue;
sscanf (line + 2, %x %x\n, offset, native_value);
value[0] = (native_value 16) 0xff;
value[1] = (native_value 8) 0xff;
value[2] = native_value 0xff;
// FIXME
if (offset 0x7000)
offset -= 0x7e5a;
pwrite (fd, value, 3, (off_t) (offset * 3));
}
close (fd);
exit (0);
}
Bug#494010: Source for dsp56k firmware
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. -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: Source for dsp56k firmware
On Wed, Oct 15, 2008 at 07:49:19PM +0200, Robert Millan wrote: 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. I think that's introduced by the BTS. - 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?). According to the assembler reference manual http://www.freescale.com/files/dsp/doc/ref_manual/DSPASMRM.pdf they mean: - I/O short addressing mode force operator - Short addressing mode force operator - Long addressing mode force operator - 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? It's a 24-bit processor and uses word-addressing, not byte-addressing. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: Digital signature
Bug#494010: Source for dsp56k firmware
You wrote: On Sun, Oct 12, 2008 at 08:10:53PM +0100, Ben Hutchings wrote: Here is the assembly-language source for the firmware, licenced under GPLv2. Very nice! Where did you find it? It was added to the upstream tree recently as part of the firmware separation effort. Adding this to the kernel source package should fix this bug. Actually, it should be assembled and used. AFAICT this is for an m68k processor. I suppose we have a command to assemble this code in binutils-multiarch or so? 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. However, as I understand it, this source was written by the same person as the driver and the binary that is embedded in it, and should assemble to exactly the same bits. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: Digital signature
Bug#494010: Source for dsp56k firmware
Here is the assembly-language source for the firmware, licenced under GPLv2. Adding this to the kernel source package should fix this bug. Ben. ; Author: Frederik Noring [EMAIL PROTECTED] ; ; This file is subject to the terms and conditions of the GNU General Public ; License. See the file COPYING in the main directory of this archive ; for more details. ; DSP56k loader ; Host Interface M_BCR EQU $FFFE ; Port A Bus Control Register M_PBC EQU $FFE0 ; Port B Control Register M_PBDDR EQU $FFE2 ; Port B Data Direction Register M_PBD EQU $FFE4 ; Port B Data Register M_PCC EQU $FFE1 ; Port C Control Register M_PCDDR EQU $FFE3 ; Port C Data Direction Register M_PCD EQU $FFE5 ; Port C Data Register M_HCR EQU $FFE8 ; Host Control Register M_HSR EQU $FFE9 ; Host Status Register M_HRX EQU $FFEB ; Host Receive Data Register M_HTX EQU $FFEB ; Host Transmit Data Register ; SSI, Synchronous Serial Interface M_RXEQU $FFEF ; Serial Receive Data Register M_TXEQU $FFEF ; Serial Transmit Data Register M_CRA EQU $FFEC ; SSI Control Register A M_CRB EQU $FFED ; SSI Control Register B M_SREQU $FFEE ; SSI Status Register M_TSR EQU $FFEE ; SSI Time Slot Register ; Exception Processing M_IPR EQU $ ; Interrupt Priority Register org P:$0 start jmp $40 org P:$40 ; ; Zero 16384 DSP X and Y words ; clr A #0,r0 ; clr B #0,r4 ; do #64,_block1 ; rep #256 ; moveA,X:(r0)+ B,Y:(r4)+ ;_block1; Zero (32768-512) Program words ; clr A #512,r0 ; do #126,_block2 ; rep #256 ; moveA,P:(r0)+ ;_block2 ; Copy DSP program control move#real,r0 move#upload,r1 do #upload_end-upload,_copy moveP:(r0)+,x0 movex0,P:(r1)+ _copy movep #4,X:M_HCR movep #$c00,X:M_IPR and #$fe,mr jmp upload real org P:$7ea9 upload movep #1,X:M_PBC movep #0,X:M_BCR nextjclr#0,X:M_HSR,* movep X:M_HRX,A move#3,x0 cmp x0,A #1,x0 jeq $0 _get_address jclr#0,X:M_HSR,_get_address movep X:M_HRX,r0 _get_length jclr#0,X:M_HSR,_get_length movep X:M_HRX,y0 cmp x0,A #2,x0 jeq load_X cmp x0,A jeq load_Y load_P do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,P:(r0)+ _load jmp next load_X do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,X:(r0)+ _load jmp next load_Y do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,Y:(r0)+ _load jmp next upload_end end signature.asc Description: This is a digitally signed message part
Bug#494010: Source for dsp56k firmware
On Sun, Oct 12, 2008 at 08:10:53PM +0100, Ben Hutchings wrote: Here is the assembly-language source for the firmware, licenced under GPLv2. Very nice! Where did you find it? Adding this to the kernel source package should fix this bug. Actually, it should be assembled and used. AFAICT this is for an m68k processor. I suppose we have a command to assemble this code in binutils-multiarch or so? -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
