19 Sep
2024
19 Sep
'24
1:58 a.m.
well, yes, on many systems, there's a lot that runs before the kernel. But
if you have a risc-v system with oreboot, you own the system. The problem
is that on most of these systems a reset will stop the dram clock for a
little bit, or glitch clock enable, or dram power, or whatever. New systems
are not designed to allow this.
Ideally, we could force a reset of everything save memory, but modern
systems are not designed in this way. Most annoying.
On Wed, Sep 18, 2024 at 4:38 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
I would prefer old kernel to new kernel handoff if it
can be made to work
reliably. Nowadays there are a lot of things that run before the kernel
gets control.
On Sep 18, 2024, at 3:38 PM, ron minnich <rminnich(a)gmail.com> wrote:
Interesting about the amiga. I'm assuming their firmware zeros memory on
reset, so you have to do handoff from kernel to kernel, not via a reset and
so on?
What was particularly nice about the V6/PDP-11 case: we were able to yank
reset, which let us cleanly reset/disable devices, because everything was
in memory when we got back. I miss the simplicity of the old machines.
On Wed, Sep 18, 2024 at 3:07 PM Christian Hopps <chopps(a)chopps.org> wrote:
We had/have this functionality in the Amiga port of NetBSD.
It is implemented as `/dev/reload` device and you copy a kernel image to
it. In locore.s there's code that copies the kernel image over top of the
running kernel and then restarts. I believe for it to work nothing below
the copy code in locore.s can change :)
Thanks,
Chris.
Phil Budne <phil(a)ultimate.com> writes:
ron minnich wrote:
> But I'm wondering: is Ed's work in 1977 the first "kernel boots
kernel" or
was there
something before?
There was! The PDP-7 UNIX listings contain a program trysys.s
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/trysys.s
that reboots the system by reading a.out into user memory (in the high
4K of core), then copies it to low memory and jumping to the entry
point. The name suggests its original intended use was to test a new
system (kernel).
P.S.
Normal bootable system images seem to have been stored in reserved
tracks of the (fixed head) disk (that are inacessible via system calls):
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/maksys.s
reads a.out and uses I/O instructions to write it out.
P.P.S.
Accordingly, I put together a "paper tape" for booting the system:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbboot.s
P.P.P.S.
The system (kernel) is 3K words, the last 1K of low memory
used for the character table for the vector graphics controller.
The definitions for the table are compiled by
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/cas.s
from definition file
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/cas.in
(after, ISTR, figuring out the ordering of the listing pages!)
I don't think we ever figured out how the initial character table
is loaded into core. One thing that was missing from the table
was the dispatch array, which I recreated:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/chrtbl.s
The system (kernel) could be built for a "cold start", reloading the
disk (prone to head crashes?) from paper tape? But I don't think
anyone ever reconstructed the procedure for rebuilding a disk that way.
The disk was two sided, and the running system only used one side:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsksav.s
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dskres.s
appear to be programs to save and restore the filesystem from the
"other" side of the disk.