headers
Gunther Nikl | 2 Jul 2003 11:21
Picon

Re: 1.6 and /dev/reload

On Fri, Jan 24, 2003 at 02:35:31PM -0700, Michael L. Hitch wrote:
> On Fri, 24 Jan 2003, Gunther Nikl wrote:
> > I have used /dev/reload on pre-1.6 from time to time
> 
> I've thought about seeing if I could change it to work with ELF kernels.

  I modified kernel_reload_write() to handle ELF kernels and now I have
  a functional /dev/reload again. I removed the aout stuff since it does
  not make any sense on an ELF system, IMO.
  The new code isn't finished yet, some tweaks are still to be done. I
  would like to get rid of the chipmem requirement. Is this possible?
  Another thought is, to only allow reboot if the machine is in single
  user mode.

  Gunther
Permalink | Reply | 9 comments |
headers
John Klos | 2 Jul 2003 21:26

Re: 1.6 and /dev/reload

Hi,

>   I modified kernel_reload_write() to handle ELF kernels and now I have
>   a functional /dev/reload again. I removed the aout stuff since it does
>   not make any sense on an ELF system, IMO.

Now that it is working for recent systems, maybe this is a good time to
ask: What does it do? I have a general idea (is it right?) that it allows
one to reboot a new kernel without rebooting the whole system from the
ROMs?

>   The new code isn't finished yet, some tweaks are still to be done. I
>   would like to get rid of the chipmem requirement. Is this possible?
>   Another thought is, to only allow reboot if the machine is in single
>   user mode.

(Forgive my ignorance; I'm guessing) Wouldn't it be better to use
/dev/reload with reboot so that reboot with a flag can bring the system
into single user mode, then use /dev/reload?

How does one use /dev/reload? I see no man page...

Thanks,
John Klos
Sixgirls Computing Labs
Permalink | Reply | 8 comments |
headers
John Klos | 3 Jul 2003 05:44

Failure to build 68060 kernel

Hi,

A while ago I posted a problem I saw when trying to compile a kernel with
-m68060 flags. The compile would typically stop like this:

ld -n -Ttext 0 -e start -S -o netbsd ${SYSTEM_OBJ} vers.o
pmap.o: In function `pmap_bootstrap':
pmap.o(.text+0x2d0): undefined reference to `DCIS_60'
pmap.o: In function `pmap_init':
pmap.o(.text+0x7e8): undefined reference to `DCIS_60'
pmap.o: In function `pmap_protect':

(and so on)

If -m68060 is in neither COPTS nor COPTFLAGS, I can recompile pmap.o (and
a few others that report problems) and it links fine.

But m68k/include/cacheops.h includes cacheops_60.h, so why isn't the stuff
defined in cacheops_60.h being missed? I'm missing something myself
here...

Thanks,
John Klos
Sixgirls Computing Labs
Permalink | Reply | 8 comments |
headers
John Klos | 3 Jul 2003 05:51

Re: Failure to build 68060 kernel

> But m68k/include/cacheops.h includes cacheops_60.h, so why isn't the stuff
> defined in cacheops_60.h being missed? I'm missing something myself
> here...

I mean why IS the stuff being missed? Well, I think anyone reading this
should know what I mean.

John Klos
Permalink | Reply | 0 comments |
headers
Gunther Nikl | 3 Jul 2003 09:52
Picon

Re: 1.6 and /dev/reload

Hello,

> >   I modified kernel_reload_write() to handle ELF kernels and now I have
> >   a functional /dev/reload again. I removed the aout stuff since it does
> >   not make any sense on an ELF system, IMO.
> 
> Now that it is working for recent systems, maybe this is a good time to
> ask: What does it do? I have a general idea (is it right?) that it allows
> one to reboot a new kernel without rebooting the whole system from the
> ROMs?

  Almost. You can't reboot any kernel: the "new" kernel must be very
  similiar to your currently running kernel. I don't know why thats
  important (there is a check in locore.s/kernel_reload). Another
  shortcoming is that chipmem is used during reboot. Your kernel must
  be smaller than chipmem size. And I forgot to say, that loading symbols
  isn't supported. Doing that was already hard with a.out kernels and it
  looks like its nearly impossible for ELF kernels. /dev/reload is a pipe
  device and loading symbols would require seeking.

> >   The new code isn't finished yet, some tweaks are still to be done. I
> >   would like to get rid of the chipmem requirement. Is this possible?
> >   Another thought is, to only allow reboot if the machine is in single
> >   user mode.
> 
> (Forgive my ignorance; I'm guessing) Wouldn't it be better to use
> /dev/reload with reboot so that reboot with a flag can bring the
> system into single user mode, then use /dev/reload?

  A "normal" reboot doesn't directly reboot into a new kernel, it transfers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gunther Nikl | 3 Jul 2003 09:58
Picon

Re: Failure to build 68060 kernel

On Wed, Jul 02, 2003 at 11:44:15PM -0400, John Klos wrote:
> A while ago I posted a problem I saw when trying to compile a kernel with
> -m68060 flags.

  Is this current or 1.6.1?

> The compile would typically stop like this:
> 
> ld -n -Ttext 0 -e start -S -o netbsd ${SYSTEM_OBJ} vers.o
> pmap.o: In function `pmap_bootstrap':
> pmap.o(.text+0x2d0): undefined reference to `DCIS_60'
> pmap.o: In function `pmap_init':
> pmap.o(.text+0x7e8): undefined reference to `DCIS_60'
> pmap.o: In function `pmap_protect':

  I always compile my kernels with -m68060 and I have never seen this.
  How do you compile your kernel? Where do you set -m68060? I believe I
  have it somehow in /etc/mk.conf.

  Gunther

--

-- 
Linux is only free if your time has no value
 - Jamie Zawinsky
Permalink | Reply | 6 comments |
headers
John Klos | 3 Jul 2003 10:46

Re: Failure to build 68060 kernel

Hi,

> > A while ago I posted a problem I saw when trying to compile a kernel with
> > -m68060 flags.
>
>   Is this current or 1.6.1?

This is 1.6.1; the last time I successfully compiled a kernel with -m68060
in COPTS and COPTFLAGS was in January.

> > pmap.o(.text+0x7e8): undefined reference to `DCIS_60'
> > pmap.o: In function `pmap_protect':
>
>   I always compile my kernels with -m68060 and I have never seen this.
>   How do you compile your kernel? Where do you set -m68060? I believe I
>   have it somehow in /etc/mk.conf.

Yes. Specifically, this is what I have:
M68060=YES
COPTS+=-m68060
CFLAGS+=-m68060
COPTFLAGS+=-m68060

As of January, I have to comment out COPTS and COPTFLAGS. It's a little
strange that something like that would change, and it's more strange since
I can't see why pmap.o would end up without functions such as DCIS_60 and
friends.

Any ideas?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ignatios Souvatzis | 2 Jul 2003 23:19
Picon

Re: 1.6 and /dev/reload

Hi,

On Wed, Jul 02, 2003 at 03:26:44PM -0400, John Klos wrote:
> Now that it is working for recent systems, maybe this is a good time to
> ask: What does it do? I have a general idea (is it right?) that it allows
> one to reboot a new kernel without rebooting the whole system from the
> ROMs?

yes. Note minor problems: e.g., some SCSI interfaces (e.g. the A3000 builtin)
only reset on a full system reset - so you sometimes can't un-hang a machine
that way. Also, the kernels have to be sufficiently similar (at least for
the old implementation) to work.

Regards,
	-is
Permalink | Reply | 6 comments |
headers
Gunther Nikl | 3 Jul 2003 14:21
Picon

Re: 1.6 and /dev/reload

Hello,

> the kernels have to be sufficiently similar (at least for the old 
> implementation) to work.

  locore.s/kernel_reload() is unchanged (BTW, I think OPT_DEVRELOAD is
  missing there) thus that constraint is still there. I am not quite sure
  why that check exists. Why shouldn't it be possible to reboot a kernel
  with a different layout? Maybe the check was there to ensure that the
  passed file really is a kernel?
  I would like to see the use of chipmem vanish. This would require to
  copy the loader at the end of of the loaded kernel image and run the
  code from there. Is that possible?

  Gunther
Permalink | Reply | 0 comments |
headers
Gunther Nikl | 4 Jul 2003 10:57
Picon

Re: Failure to build 68060 kernel

Hello!

> This is 1.6.1; the last time I successfully compiled a kernel with -m68060
> in COPTS and COPTFLAGS was in January.

  I don't have -m68060 in any C related flag settings.

> M68060=YES

  This is ok.

> COPTS+=-m68060
> CFLAGS+=-m68060

  I have commented these lines.

> COPTFLAGS+=-m68060

  I have such a line but without the "+" meaning _I_ define the optimization
  flags on my own:

    COPTFLAGS=-O -fomit-frame-pointer

  The kernel itself is compiled with -m68060 (atleast on my setup) because
  the generated Makefile has an IDENT line containg -DM68060. This then
  selects a CFLAGS specifying -m68060.

  Note: Apparently, there is a nasty bug using -fomit-frame-pointer with
  sources that use floats, eg. libxpm or libjpeg. If I compile either
  library with -fomit-frame-pointer then programs using this library
(Continue reading)

Permalink | Reply | 4 comments |

Gmane