Re: hardclock(9) for cobalt

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
Date: Sat, 31 Jul 2004 22:39:32 +0900

> The problem is that softclock is _scheduled_ (not called yet
> at that time) in hardclock(9) before softclock_si is initialized
> (i.e. softclock is established) in sys/kern/kern_clock.c:initclocks().
> Then it may occur if there is any device which uses callout(9).

I also think so.
Can I do?
--
kiyohara

Re: hardclock(9) for cobalt

In article <20040801.221246.74749108.kiyohara <at> kk.iij4u.or.jp>
kiyohara <at> kk.iij4u.or.jp wrote:

> > The problem is that softclock is _scheduled_ (not called yet
> > at that time) in hardclock(9) before softclock_si is initialized
> > (i.e. softclock is established) in sys/kern/kern_clock.c:initclocks().
> > Then it may occur if there is any device which uses callout(9).
> 
> I also think so.
> Can I do?

According to cobalt/machdep.c:cpu_intr() and GT-64111 manual
(though cobalt actually uses GT64011), bit 8 on 0x14000c18 is
tested so cobalt uses Timer0 for hardclock(9).

I guess you could control the timer by Timer/Counter control
register (offset 0x864), so you can disable it somewhere
during cpu_configure(9) and enable it again in cpu_initclocks(9).

Maybe we should attach the timer as usual device and initialize
it in the attachment, and functions which enable the timer that
will be called from cpu_initclocks(9) should also be registered
in the attachment (like mvme68k or news68k .
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp

No output to the console

I recently upgraded the entire Qube to 2.0-release from a release
build I did a few weeks ago. That all went OK. I then did a cvs update
of the 2.0-release source tree a few days ago, and built a new kernel
with virtually the same config file (the only differences were for the
semaphores use of memory for postgresql), and suddenly the serial
console stops logging anything. I think even the bootloader wasn't
coming through, but it was booting because eventually I could log in
from remote. It stopped right after the firmware started loading the
"kernel", which is actually the bootloader I think.

Any idea what's happening? I'm re-building using the config file from
the kernel that got built during the release build I did a few weeks
ago to see if it still works.

Andy

Can't build a kernel in 2.0-release

I've updated my 2.0-release source tree yesterday, and today I can't
build a kernel. On the cobalt itself, it fails with this:

nbmake: don't know how to make machine/wchar_limits.h. Stop

And on a cross build from an i386 machine using 2.0-release, I get this:

obalt/compile/TAZ3-2.0r/lib/kern/libkern.a vers.o swapnetbsd.o
*** Error code 1

Stop.
nbmake: stopped in /home/build/obj/sys/arch/cobalt/compile/TAZ3-2.0r

ERROR: Failed to make all in /usr/src/../obj/sys/arch/cobalt/compile/TAZ3-2.0r
*** BUILD ABORTED ***

On both I am using build.sh after rebuilding the tools fresh.

Any ideas?

Andy

Qube 2700 Serial Console

Hi All,
I want to try and build a serial console for my Qube2700. Unfortunately the I/Cs 
listed in Jamie Heilman's schematic are no longer in production and I can't find 
a replacement foe one of them.

Having spoken to Jamie he suggested that someone on the mailing list had built a 
serial console reasonably recently using different I/Cs. I search through the 
mailing list archives but couldn't find anything useful.

Soooo... has anyone out there built a serial console recently, and if so, could 
you provide your schematics?

Thanks guys,
Lucien.
--

-- 

Lucien Wells, lwells <at> bigpond.net.au on 7/08/2004

Re: Qube 2700 Serial Console

Lucien Wells wrote:
> Hi All, I want to try and build a serial console for my Qube2700.
> Unfortunately the I/Cs listed in Jamie Heilman's schematic are no
> longer in production and I can't find a replacement foe one of them.
> 
> Having spoken to Jamie he suggested that someone on the mailing list
> had built a serial console reasonably recently using different I/Cs.
> I search through the mailing list archives but couldn't find
> anything useful.

The someone was Ray Dekens, he used a SMT 8530 and ds14c238.
http://mail-index.netbsd.org/port-cobalt/2003/03/21/0000.html
http://mail-index.netbsd.org/port-cobalt/2003/06/14/0000.html

--

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly,
 she's not for you." She was cheap, she was stupid and she wouldn't
 load -- well, not for me, anyway."                     -Holly

help disk error -> single user mode

Hi cobalt user and experts

my cobalt disk got problems. After booting the file checking reported 
a disk error which couldn't be fixed. The machine ends up in a single 
user mode. However the main partion is mounted.

Does anyone know if I can start the cobalt without fsck and hopefully 
getting the machine in the mutiuser mode so I could back up the disk

frank
--

-- 
Frank Mattes, MD			e-mail:	f.mattes <at> ucl.ac.uk
Department of Virology			fax	0044(0)207 8302854
Royal Free Hospital and 			tel	0044(0)207 8302997
University College Medical School
London

Re: hardclock(9) for cobalt

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
Date: Mon, 2 Aug 2004 00:41:09 +0900

> I guess you could control the timer by Timer/Counter control
> register (offset 0x864), so you can disable it somewhere
> during cpu_configure(9) and enable it again in cpu_initclocks(9).

I tested, stop counting for timer0, if a timer0 was disable (offset
0x864: bit 0).

 
> Maybe we should attach the timer as usual device and initialize
> it in the attachment, and functions which enable the timer that
> will be called from cpu_initclocks(9) should also be registered
> in the attachment (like mvme68k or news68k .

OK! I try now.
Are required function attach, match, start, and stop? 
--
kiyohara

Re: hardclock(9) for cobalt

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
Date: Mon, 2 Aug 2004 00:41:09 +0900

> Maybe we should attach the timer as usual device and initialize
> it in the attachment, and functions which enable the timer that
> will be called from cpu_initclocks(9) should also be registered
> in the attachment (like mvme68k or news68k .

How is it now?

  gttmr0 at mainbus0: 32bit-Wide Timer/Counter on GT-64111

hardclock(9) is not called before being able to initialize softclock_si
now. That is, I think that it becomes safe. 

microtime(9) uses timer0.
Probably, it will be better to add microtime(9) here, if possible.

--
kiyohara

Index: arch/cobalt/cobalt/clock.c
===================================================================
RCS file: /cvsroot/src/sys/arch/cobalt/cobalt/clock.c,v
retrieving revision 1.7
diff -c -r1.7 clock.c
*** arch/cobalt/cobalt/clock.c	5 Jul 2004 07:28:45 -0000	1.7
--- arch/cobalt/cobalt/clock.c	10 Aug 2004 16:56:55 -0000

getting started with Qube 2

Hello,

I just received a Qube 2 box and installed NetBSD 1.6.2; runs fine
so far. A few questions:

- Is there a way to select the boot device (without recompiling the
  kernel)? Before NetBSD was installed on wd0, netbooting the Qube
  worked fine: I was asked for boot (tlp0) and dump device (none) and
  for the root fs type (nfs). But now the boot device is always assumed
  to be wd0, even if I try to netboot the box (using
  'bfd /netbsd.gz nfsroot=/path/to/nfs/root').

- In the port-cobalt mailing list archive[1] I read about paneld, but
  can't find such a script in /etc/rc.d. In a different message[2] I
  saw a dmesg output containing 'lcd0 at mainbus0'; however, there's
  no such name (and no /dev/lcd device) on my system. What am I missing?

- I'm using a serial console, running at 115200 baud. If I connect
  at 9600 baud instead and hit a key (i.e. send a character to the Qube),
  the kernel drops into ddb. Is this a known bug, or should I send-pr?

TIA, Jukka

[1] http://mail-index.netbsd.org/port-cobalt/2004/07/21/0010.html
[2] http://mail-index.netbsd.org/port-cobalt/2004/07/12/0001.html

--

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~