Problem with bus_dma(9) on 68020 and 68030 systems

I found that, when trying to build for `options M68030' only, that the
DC[FP][LP]() macros in _bus_dmamap_sync() -- data cache
{flush,purge}{line,page} -- are undefined for the M68020 only and
M68030 only cases. Worse, much worse, in the _MULTI_CPU case, it
indeed compiles, but it looks like the M68040 instruction will always
be executed on the lesser processors.

Could this account for an apparent FPU exception being taken in the
kernel:

  http://mail-index.netbsd.org/port-mac68k/2002/05/29/0008.html

or must there be still another problem?

In the following patch, I went ahead and filled in all the blanks with
macros that expand to nothing (to preserve parallelism and prevent
such problems in the future). Does this look OK? Does it need another
comment: something to the effect, "68020 has no data cache, 68030's is
write-through"?

Index: include/cacheops.h
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/m68k/include/cacheops.h,v
retrieving revision 1.8
diff -u -r1.8 cacheops.h
--- include/cacheops.h	2000/04/05 19:38:33	1.8
+++ include/cacheops.h	2002/06/01 02:18:32
 <at>  <at>  -61,6 +61,14  <at>  <at> 
 #define	DCIU()		DCIU_20()
 #define	DCIAS(pa)	DCIAS_20((pa))

NeXTStation Turbo port

Hello,

I notice in your hardware list that there is a port for the NeXT 68040 25MHz
hardware, but not for 33MHz hardware (like mine, apparently--a NeXTStation
Color Turbo, Model 1200).  Do you know if one is planned, or if there is
another distro that supports this?

Also, what is entailed in creating a new port?  I'm a programmer, so if it
wouldn't be a monumental effort to create this port I'd be interested in
what it would take.

Thanks,
Ian

Re: NeXTStation Turbo port

On Fri, 21 Jun 2002, Ian Calegory wrote:

> I notice in your hardware list that there is a port for the NeXT 68040 25MHz
> hardware, but not for 33MHz hardware (like mine, apparently--a NeXTStation
> Color Turbo, Model 1200).  Do you know if one is planned, or if there is
> another distro that supports this?
>
> Also, what is entailed in creating a new port?  I'm a programmer, so if it
> wouldn't be a monumental effort to create this port I'd be interested in
> what it would take.

It very likely wouldn't require a new port, but only changes/additions
to next68k. Best to ask on port-next68k.

Frederick

Re: NeXTStation Turbo port

On Fri, Jun 21, 2002 at 11:42:57AM -0400, Ian Calegory wrote:

 > I notice in your hardware list that there is a port for the NeXT 68040 25MHz
 > hardware, but not for 33MHz hardware (like mine, apparently--a NeXTStation
 > Color Turbo, Model 1200).  Do you know if one is planned, or if there is
 > another distro that supports this?

We need documentation on how the memory controller and other bits of
hardware in the Turbo works.  The Turbo machines are quite different.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

NEED TESTERS: minor change to signal delivery

Can someone please apply this patch to their source tree, rebuild
the kernel, boot it, and verify that signals still work?  It should
be fine, as I can't see anything that relies on the ordering of the
sigcontext and the sigstate in the sigframe (and since the sigcontext
has a pointer to the sigstate, userland doesn't rely on the ordering,
either).

I don't have any m68k machines running at the moment, so can't test it
easily myself.

Please ASAP, as I want to get these signal changes I'm working on
done quickly 

Thanks!

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Index: include/signal.h
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/m68k/include/signal.h,v
retrieving revision 1.8
diff -u -r1.8 signal.h
--- include/signal.h	1998/09/30 21:52:45	1.8
+++ include/signal.h	2002/06/23 03:52:43
 <at>  <at>  -104,8 +104,8  <at>  <at> 
 	int	sf_code;		/* additional info for handler */
 	struct sigcontext *sf_scp;	/* context pointer for handler */
 	sig_t	sf_handler;		/* handler address for u_sigc */

OMAGIC a.out !?

Hi,

I've a difficulty of producing OMAGIC a.out executable.  I used to run
ld to produce OMAGIC a.out executables w/ "-N" flag given.   I noticed
that ELF/m68k toolchain seems not to honour -N flag.  Despite man ld
implies a.out, it makes ELF files.  I tried m68k--netbsdelf-objcopy and
resulted in vain.  It complains .rodata section not allowed for a.out.  Exact
message is as follow;

BFD: st26938a: can not represent section `.rodata' in a.out object file format
/tools/bin/m68k--netbsdelf-objcopy: st26938a: Nonrepresentable section on output

It's necessary for luna68k boot ROM monitor to have OMAGIC kernel to boot off.
I think similar issues matter for sun2/sun3 ports.  Solutions welcome.

Toru Nishimura/ALKYL Technology

Re: OMAGIC a.out !?

In article <000701c21d35$868f36c0$0d00a8c0 <at> paq5>,
Toru Nishimura <locore32 <at> gaea.ocn.ne.jp> wrote:

Check what the contents of .rodata is [what data is in there] and try to
eliminate them by either specifying -fwritable-strings or changing the
source code. Alternatively fix objdump to merge data and rodata sections.

objdump --full-content is your friend.

christos

>Hi,
>
>I've a difficulty of producing OMAGIC a.out executable.  I used to run
>ld to produce OMAGIC a.out executables w/ "-N" flag given.   I noticed
>that ELF/m68k toolchain seems not to honour -N flag.  Despite man ld
>implies a.out, it makes ELF files.  I tried m68k--netbsdelf-objcopy and
>resulted in vain.  It complains .rodata section not allowed for a.out.  Exact
>message is as follow;
>
>BFD: st26938a: can not represent section `.rodata' in a.out object file format
>/tools/bin/m68k--netbsdelf-objcopy: st26938a: Nonrepresentable section on output
>
>It's necessary for luna68k boot ROM monitor to have OMAGIC kernel to boot off.
>I think similar issues matter for sun2/sun3 ports.  Solutions welcome.
>
>Toru Nishimura/ALKYL Technology
>
>

Re: OMAGIC a.out !?

On Wed, Jun 26, 2002 at 06:29:37PM +0000, Christos Zoulas wrote:

 > Check what the contents of .rodata is [what data is in there] and try to
 > eliminate them by either specifying -fwritable-strings or changing the
 > source code. Alternatively fix objdump to merge data and rodata sections.
 > 
 > objdump --full-content is your friend.

The right fix is to write a linker script which arranges things in
the correct faction, and possible even emits a.out directly.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

assembler syntax

Hi,

I am unfamiliar with gcc/as assembler syntax (gcc 2.95.3, as 2.11.2,
NetBSD 1.6_BETA3). The following code has a problem:

  int vgar(volatile caddr_t ba, int idx)
  {
  register int erg;
  asm volatile ("movel %1, a0;\
                  movel %2,d1;
                  movel a0 <at> (d1), %0;" :\
                  "=r" (erg):\
                  "g" (ba), "d" (idx) :\
                  "a0", "d0", "d1");
  return erg;
  }

This gets translated into:

  ...
  #APP
          movel %d2, a0;                movel %d3,d1;
                  movel a0 <at> (d1), %d2;
  #NO_APP
  ...

and 'as' complains about:

  /tmp/cc1Pws5c.s:41: Error: syntax error -- statement `movel a0 <at> (d1),%d2' ignored

Re: assembler syntax

On Sun, Jun 30, 2002 at 06:25:56AM +0200, Klaus Heinz wrote:

> and 'as' complains about:
> 
>   /tmp/cc1Pws5c.s:41: Error: syntax error -- statement `movel a0 <at> (d1),%d2' ignored
> 
> 
> From what I have found, I think every register name should be preceded by
> a '%' (%% in the C source file).

you could do that, or pass the --register-prefix-optional argument to
the assembler.

> Without the % in front of the register names, 'as' translates the above
> (according to objdump) to:
> 
>   10:   23c2 0000 0000  movel %d2,0 <vgar>
>   16:   23c3 0000 0000  movel %d3,0 <vgar>
>   1c:   2430 0170 0000  movel %a0 <at> (00000000),%d2
> 
> which seems not to be the intended output:
> 
>   10:   2042            moveal %d2,%a0
>   12:   2203            movel %d3,%d1
>   14:   2430 1800       movel %a0 <at> (00000000,%d1:l),%d2
> 
> 
> Can someone confirm this?

your assumptions appear correct.