Bootblock completion function

[hop]

I've written a bootblock trackdisk hunk loader and it's all working fine. Currently to execute the loaded code, the address of the entry point is loaded into A0 and jumped to:

; BB Header
	<load hunk file>
	<clear caches>
	movea.l rootHunks(pc),a0  ; first root hunk memory
	jmp (a0)
...
rootHunks:	ds.l	MAX_ROOT_HUNKS	; table of pointers (32-bit addresses, longwords)

I thought this was OK, but I might as well do it properly and let the system free the bootblock memory:

3. The boot code returns with results in both D0 and A0.

a) Non-zero D0 indicates boot failure. The recoverable alert
AN_BootError is presented before continuing.

b) Zero D0 indicates A0 contains a pointer to the function to
complete the boot. This completion function is chained to with
SysBase in A6 after the strap module frees all its resources.
It is usually the dos.library initialization function, from the
dos.library resident tag. Return from this function is
identical to return from the strap module itself.

http://amigadev.elowar.com/read/ADCD.../node007D.html

; BB Header
	<load hunk file>
	<clear caches>
	movea.l rootHunks(pc),a0	; first root hunk memory
	moveq #0,d0
	rts
...
rootHunks:	ds.l	MAX_ROOT_HUNKS	; table of pointers (32-bit addresses, longwords)

However this doesn't seem to work and end up with a Guru invalid instruction.

Perhaps I have misunderstood this, or there is a bug in my implementation.

[paraj]

At what address does it fail? Is your code called? (put a breakpoint on the first instruction
of the loaded code). Check that the stack pointer is the same when you return as it was on entry.

KS1.3 (and probably the others) do very little between returning from the BB code and doing literally "JMP (A0)" itself, just cleanup and adding a DF0 DosNode.

Maybe you're corrupting some OS data structures or use too much stack for yourself (not sure if that can be an issue though).

[phx]

Originally Posted by hop

b) Zero D0 indicates A0 contains a pointer to the function to complete the boot.

This is important. The OS does not expect any function pointer in

A0

, but a function which initialises dos.library, so the system can complete the boot. If you return from the boot block you must have called

FindResident("dos.library")

and return a pointer to its init function. Nothing else.

I'm sure Thomas can provide you with more details.

[paraj]

Originally Posted by phx

This is important. The OS does not expect any function pointer in

A0

, but a function which initialises dos.library, so the system can complete the boot. If you return from the boot block you must have called

FindResident("dos.library")

and return a pointer to its init function. Nothing else.

I'm sure Thomas can provide you with more details.

If for whatever reason the code is fine with just using exec, graphics and trackdevice shouldn't it still be fine (like OPs code, since it works without returning)?


Made a quick test boot block, that allocates some memory, copies some fixed code there and it runs just fine (and can call exec).


The linked doc even says "It is usually the dos.library initialization function" indicating that it could be something else.

[ross]

You can examine my addchip bootblock: https://eab.abime.net/showpost.php?p...3&postcount=25

[phx]

Originally Posted by paraj

If for whatever reason the code is fine with just using exec, graphics and trackdevice shouldn't it still be fine (like OPs code, since it works without returning)?

It would certainly be fine, when DOS is initialised in the end. But hop's last example just shows that the boot block returns to the OS with his private function in a0. It is unknown if this routine does the DOS-initialisation itself, like in Ross' example. I assumed it didn't.

The linked doc even says "It is usually the dos.library initialization function" indicating that it could be something else.

It was probably the plan to support other disk operating systems. Don't know if it really works.

Only hop can answer what his code-hunk is really doing. Maybe it just returns with

RTS

, which could explain the Guru.

[Galahad/FLT]

Originally Posted by phx

It would certainly be fine, when DOS is initialised in the end. But hop's last example just shows that the boot block returns to the OS with his private function in a0. It is unknown if this routine does the DOS-initialisation itself, like in Ross' example. I assumed it didn't.

It was probably the plan to support other disk operating systems. Don't know if it really works.

Only hop can answer what his code-hunk is really doing. Maybe it just returns with

RTS

, which could explain the Guru.

His code hunk likely still has its AmigaDOS executable stuff appended to the front, so is his code hunk PC relative? If not PC relative has the code been properly relocated?

If he hasn't done that, he's not bypassing the first 32 bytes which can sometimes be interpreted as code when its not.

[Thomas Richter]

Originally Posted by phx

This is important. The OS does not expect any function pointer in

A0

, but a function which initialises dos.library, so the system can complete the boot. If you return from the boot block you must have called

FindResident("dos.library")

and return a pointer to its init function. Nothing else.

I'm sure Thomas can provide you with more details.

Well, it works as stated. If your code returns with d0=0, then a0 is assumed to be a function pointer to a function that completes the boot. The standard os boot block continues with the dos.library init function, but it can be any other function as well. This other function is not "expected to return" to anything, it just does the booting and takes over the system. If the function returns, then the ROM code runs into WarmCapture (in exec), and then just stops the system with a colored background.



Note, however, that if that other function is in your boot block, you have a problem because the memory of your boot block is released after you return, and thus the Os jumps into the wild. IOWs, you need to be sure that this other function runs on its own memory, so you have to allocate memory on your own, and copy or load this other function to this place.



The reason for this indirection was that CBM envisioned that some other Dos than Tripos could be used on top of AmigaOs, thus the dos.library is just one potential candidate DOS a boot block could initiate.


The dos.library itself initializes itself, then initializes remaining ROM modules, and then the situation differs a bit: Under 3.1.4 and below, it starts a shell (the Initial CLI), then terminates. The initial CLI then initializes the remaining system as part of its InitCLI() function (which is an internal function in the dos.library).


In 3.2, this is somewhat different. Dos Init there starts System-startup, then termintes itself, and System-startup initializes the rest of the system, and as last step, it lauches the initial CLI and then quits. It's like the "Init" process of of Unix that takes care of mounting devices and triggering the initial shell.

[hop]

Thanks for all the responses.

Please find attached loader and loadfile source to provide more context (EDIT: To assemble, requires latest build of vasm to support ASSERT directive)

My loadfile(s) are not initialising the dos library. I hope this is not a requirement. I was under the impression that the boot process was designed to be flexible, providing the open IO trackdisk request and calling an arbitrary function at the end of it. I didn't realise the Completion Handler had to init DOS. Seems very restrictive. If this is the case, then I guess a JMP is the only option and the bootblock memory can never be reclaimed, unless the system is completely taken-over.

It doesn't look like even my simple artificial loadfile is being called.

Stack is not being corrupted.

I have confirmed that the loadfile is being correctly relocated.

I have been testing under stock A500 Kickstart 1.3.

[hop]

Originally Posted by Thomas Richter

Well, it works as stated. If your code returns with d0=0, then a0 is assumed to be a function pointer to a function that completes the boot. The standard os boot block continues with the dos.library init function, but it can be any other function as well.

Thanks. This is very reassuring and good design! There must be another issue with my loader.

Originally Posted by Thomas Richter

you need to be sure that this other function runs on its own memory, so you have to allocate memory on your own, and copy or load this other function to this place.

This is the case. Hunk memory is AllocMemed and relocated as appropriate.

[hop]

Originally Posted by Galahad/FLT

His code hunk likely still has its AmigaDOS executable stuff appended to the front, so is his code hunk PC relative? If not PC relative has the code been properly relocated?

If he hasn't done that, he's not bypassing the first 32 bytes which can sometimes be interpreted as code when its not.

The hunk loadfile is parsed properly, starting with the header, so I'm pretty sure it all works as it should. In fact the loader works just fine if the entry point is JMPed to, rather than in A0 after RTS.

[hop]

Originally Posted by ross

You can examine my addchip bootblock: https://eab.abime.net/showpost.php?p...3&postcount=25

Thanks for this. It looks like preserving all registers might have fixed it!

; BB Header
	movem.l d0-d7/a0-a6,-(sp)
	<load hunk file>
	<clear caches>
	movem.l (sp)+,d0-d7/a0-a6
	movea.l rootHunks(pc),a0	; first root hunk memory
	moveq #0,d0
	rts
...
rootHunks:	ds.l	MAX_ROOT_HUNKS	; table of pointers (32-bit addresses, longwords)

I'm not sure why this is? I might have trashed something accidentally, or perhaps this is another requirement for the bootblock code?

EDIT: Perhaps the bootblock code has to adhere to the OS calling convention and is allowed to trash d0-d1/a0-a1 but must preserve all others?

[ross]

Originally Posted by hop

EDIT: Perhaps the bootblock code has to adhere to the OS calling convention and is allowed to trash d0-d1/a0-a1 but must preserve all others?

This.

[hop]

Originally Posted by ross

This.

Makes perfect sense. A bootblock is a system call so when writing one the user has to follow the conventions. Unfortunately this is likely to be the only system call that most people will ever write!

If possible, it might be worth explicitly stating this at

• https://wiki.amigaos.net/wiki/Amiga_...hysical_Layout
  http://amigadev.elowar.com/read/ADCD.../node007D.html

[StingRay]

Originally Posted by hop

Unfortunately this is likely to be the only system call that most people will ever write!

Could you please elaborate what you mean with this statement? Because if it means what I think it does, it is completely wrong!

[hop]

Originally Posted by StingRay

Could you please elaborate what you mean with this statement? Because if it means what I think it does, it is completely wrong!

Apologies - I'm new to this game. Thanks for any clarification.

What I mean is that most coders call system calls e.g. AllocMem from their application code, and and have to remember that d0-d1/a0-a1 could be trashed internally but their other registers they have used will be preserved.

When a bootblock is written by the user, the system calls into the bootblock (application code), so this time the user has to manually implement the same system convention. Kind of upside down.

I guess I'm wrong here because there a calls like Supervisor() userfunc which follow the same callback type pattern.