[TUHS] kernel boots kernel in 1977

[Bakul Shah via TUHS]

> On Sep 18, 2024, at 5:53 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> On Wed, Sep 18, 2024 at 8:05 PM Bakul Shah via TUHS <tuhs at tuhs.org> wrote:
>> Can you not avoid resetting the machine? This can be treated almost as sleep in the old kernel, wakeup in the new one! You do have to reset devices individually (which may not always work if it requires assistance from some undocumented firmware).
> 
> Perhaps this is what you mean when you mention assistance from
> firmware, Bakul, but it may be useful to consider that _many_ devices
> are touched by e.g. a BIOS or UEFI or whatever well before the OS is
> even loaded.

Right but presumably the old kernel leaves them in a good enough state.

> If one steps back and considers the utility of a BIOS/UEFI (and I
> often lump these into the same category), there are three principal
> reasons for it: 1) back in the bad old days, we could offload common
> IO functions into code stored on a ROM, freeing up precious RAM for
> programs. 2) firmware provides a layer of indirection between the
> system and the host software, allowing both to vary while continuing
> to work with newer versions of the other. And finally 3) firmware
> facilitates bootstrapping the system by providing the host some way to
> access devices and locate and load an OS image, er, before the OS
> image is loaded. SOMETHING has to get enough code loaded from
> somewhere to start the system; often times that's firmware.

The new OS image is already in memory but may need to be copied to
the right place. The devices were already working (but may need to
have their interrupts disabled and any DMA stopped etc.).

> Anyway, the last two suggest that device state can be arbitrarily
> munged before the OS takes over, and an actual reset at the device
> level might wipe out some state the OS depends on. Consider, for
> example, programming PCI BARs; on a "modern" x86-64 system with UEFI,
> this is done by firmware in the PEI layer, and the OS may expect that
> to already be set up by the time it is probing buses. An actual
> honest-to-goodness reset will probably wipe the BARs, requiring the
> host OS to program them (ironically, many OSes are already equipped to
> do so, as they have to handle these cases for e.g. PCI hotplug events,
> though many don't do it in the "ordinary" discovery and initialization
> phase of boot).

All that is done on powerup.

> 
> I suppose the point is that a reset is great because it really does
> wipe out state, but it may also be a bummer because, well, it really
> does wipe out state. :-)

:-) I was speculating that kernel to kernel warmboot should be doable.


> 
>        - Dan C.
> 
>> On Sep 18, 2024, at 4:58 PM, ron minnich <rminnich at gmail.com> wrote:
>> 
>> 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 at 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 at 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 at 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 at 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.
>>>> 
>>> 
>>