|
Replies:
11
-
Pages:
1
-
Last Post:
Dec 20, 2018 4:23 PM
Last Post By: Dan8
|
|
|
Posts:
493
Registered:
7/25/12
|
|
|
|
netBOOT ROM driver
Posted:
Aug 7, 2012 8:20 PM
|
|
|
|
There are netBOOT and ATBOOT device drivers in most 68k mac ROMs from the IIsi and up. There is even a mention to network booting in the IIsi dev notes.
I've been unable to find much information about these drivers online, so have been working on figuring out out how they work.
The progress so far is a small tool to set PRAM values sufficient to activate the driver at boot and cause it to send out a boot request with an unknown DDP protocol type. nbpram0.1.cpt.hqx
When the machine reboots after the tool has been run and the PRAM values are set, the screen will show a blank disk icon (similar to the flashing question mark disk, without the question mark), it will then send out some zone information requests, then do an NBP lookup for the server, and if it gets a response, send that server a request with DDP protocol 0x0a.
Here are some of my notes about what is going on:
The .netBOOT driver will be installed and opened if bit 0x80 is set in the byte located in offset 7 of PRAM.
If this flag is not set, the driver will not be opened.
If cmd-opt-n-b are held down, the driver will be opened, then the 0x80 flag above will be cleared, apparently to prevent subsequent netboots.
Holding down the control key will bypass netboot and continue normal booting, leaving PRAM state as is.
The netboot driver will then create a drive queue element that the system will later try to boot off.
When the system tries to boot off this "drive", the netBOOT driver gets a read/Prime call, which will check the protocol byte stored in PRAM and if set to 1, will load and synchronously open the .ATBOOT driver.
The .ATBOOT driver will then load and open the appletalk driver (.MPP).
Once the .netBOOT's synchronous open of the .ATBOOT driver returns back to the .netBOOT's read/Prime call, it will issue a Control call to the .ATBOOT driver with csCode 1,
The .ATBOOT Control call will then query for a server to boot from. The server queried for is determined by a 16bit server id number, which is then translated to an ascii encoded hex representation of the short. Except the ascii sting is backwards (not byteswpped). So, a server id of 0xEBAB will be translated into a server name of "BABE". The appletalk Service type used is "BootServer". So, "BABE:BootServer".
If something on the network responds to that NBP lookup request, it then sends the responding server a DDP packet of protocol 0x0A. This packet contains the machineID and the username, both stored in PRAM. |
|
Posts:
493
Registered:
7/25/12
|
|
|
|
Re: netBOOT ROM driver
Posted:
Aug 9, 2012 9:00 PM
in response to: bbraun
|
|
To clarify, I did the test below on a 660av.
Investigating some more on the IIsi ROM, the .netBOOT driver is not actually enabled. To explain what that means, here is the ROM code to load the .netBOOT driver:
P_mInitNetBOOT:
1250 2149 0012 Move.L A1, $12(A0)
1254 A000 _Open
1256 2F08 Move.L A0, -(A7)
1258 594F SubQ.L $4, A7
125A 2F3C 4452 5652 Move.L $44525652, -(A7) ; DRVR
1260 487A 0016 Pea.L DT28
1264 A9A1 _GetNamedResource
1266 4A9F Tst.L (A7)+
1268 205F Move.L (A7)+, A0
126A 670A BEQ L188
126C 43FA 000A Lea.L DT28, A1
1270 2149 0012 Move.L A1, $12(A0)
1274 A000 _Open
1276 4E75 L188: Rts
1278 082E 6E65 7442 DT28: DC.B ' .netB'
127E 4F4F 5400 DC.B 'OOT '
Essentially this code is trying to GetNamedResource('DRVR', "\p.netBOOT"), and if that succeeds, open the .netBOOT driver. This is actually not necessary, since _Open will fail if the driver doesn't exist, and we're not actually caring about the return value of _Open anyway.
But, that doesn't explain why it is disabled. It is disabled because there are flags associated with each ROM resource, and one of them tells the ResourceManager to ignore the resource.
The Resources in the ROM are structured like this:
Offset 0x1A in the ROM is an offset to resource information:
1A 0007 EC10 DC.L $0007EC10 ; offset to resources
At this location is an offset (from the beginning of ROM) to the first resource:
7EC10 0007 EB90 0408 DC.B ' '
This (0x7EB90) is the first resource in a list of resources in the ROM:
0007eb90 78 00 00 00 00 00 00 00 00 07 eb 10 00 07 eb c0 |x...............|
0007eba0 43 55 52 53 00 01 58 00 5b 11 54 75 65 2c 20 4a |CURS..X.[.Tue, J|
0007ebb0 75 6c 20 31 c0 a0 00 00 00 00 00 50 00 00 00 5c |ul 1.......P...\|
The offset to the next resource is located at +8 bytes (7EB10 in this case). But the important bit here is the first byte in the resource entry: 0x78. For some comparison, the .Sony driver:
0006c3b0 78 00 00 00 00 00 00 00 00 06 ab 60 00 06 c3 e0 |x..........`....|
0006c3c0 44 52 56 52 00 04 58 05 2e 53 6f 6e 79 44 3e 3e |DRVR..X..SonyD>>|
0006c3d0 5b 28 63 29 c0 a0 00 00 00 00 46 c0 00 00 01 84 |[(c)......F.....|
and the .netBOOT driver:
00051d40 18 00 00 00 00 00 00 00 00 00 00 00 00 05 1d 70 |...............p|
00051d50 44 52 56 52 00 31 58 08 2e 6e 65 74 42 4f 4f 54 |DRVR.1X..netBOOT|
00051d60 74 65 72 2c c0 a0 00 00 00 00 07 d0 00 00 02 44 |ter,...........D|
The .Sony driver is loaded and the .netBOOT driver is not. Changing that to 78 instead of 18 causes the driver to be loaded. |
|
Posts:
493
Registered:
7/25/12
|
|
|
|
Re: netBOOT ROM driver
Posted:
Aug 19, 2012 8:44 PM
in response to: bbraun
|
|
|
|
|
I'm now sending the Disk Tools disk image, which I don't currently know if that's in a format the netboot driver wants, it's just something to try.
It's not booting the file, but there is a cute progress indicator. The blank Mac icon above gets filled in with eyes, nose, and mouth as pieces of the netboot image are received. Attached is a little video of the boot process so far.
Message was edited by: bbraun
Attached video
|
|
Posts:
1
Registered:
1/16/13
|
|
|
|
Re: netBOOT ROM driver
Posted:
Jan 16, 2013 4:42 PM
in response to: bbraun
|
|
Just curious, have you seen the source code for this driver? There's a lot more to it that you haven't mentioned... 
(namely, some sort of image validation stuff)
Edit: Oh, and the netboot driver only expects the boot blocks... there's actually two drivers involved. I suspect they had custom boot blocks in mind that could load from an AFP share.
Message was edited by: techfury90 |
|
Posts:
493
Registered:
7/25/12
|
|
|
|
Re: netBOOT ROM driver
Posted:
Jan 16, 2013 10:18 PM
in response to: techfury90
|
|
|
Yeah, I've seen it. It's helpful. But the netboot driver is disabled (its resource entry has an "ignore" bit set) in all pre-AV ROMs, so you'd need the custom ROM to use it anyway. It would probably be easier to implement a different netboot driver.
I've implemented a driver that copies a file from an AFP server into ROM and treats it like a ramdisk, but appletalk isn't actually initialized in ROM prior to OS boot. This netboot driver has code to enable it, which would be a useful starting point to doing it myself, but it is rather involved.
Anyway, it would be nice to have a working netboot server and bits it can boot, but the TODO backlog is long, and this isn't near the top.
|
|
Posts:
10
Registered:
6/30/13
|
|
|
|
Re: netBOOT ROM driver
Posted:
Jun 30, 2013 5:33 PM
in response to: bbraun
|
|
|
I spent a fair amount of time poking at this as well, and was greatly pleased to find this thread. I never go around to writing a server for it either, but I do remember finding the source and noting a "command-option-N-B" keyboard combination that was supposed to do something at boot time. Also never got around to trying this. I'd be interested to read if you'd made any progress lately.
|
|
Posts:
3
Registered:
12/14/16
|
|
|
|
Re: netBOOT ROM driver
Posted:
Nov 22, 2018 11:05 PM
in response to: bbraun
|
|
The first byte in a ROM resource header is the 'combo bitfield'. It specifies which combos activate the resource.
0x78 means that the resource shows up for combos 3,4,5, and 6.
0x18 means that the resource shows up for combos 3 and 4.
The Resource Manager reads the combo number from pram byte 0xAE.
Setting it to 3 or 4 should enable NetBoot.
This information was gathered by looking through a github repo of the leaked ROM sources modified to actually build the latest PowerPC version of it.
https://github.com/elliotnunn/CubeE |
|
Posts:
493
Registered:
7/25/12
|
|
|
|
Re: netBOOT ROM driver
Posted:
Nov 28, 2018 8:36 PM
in response to: Dan8
|
|
|
Neat. I hadn't seen anything about enabling those resources before. The AV macs didn't seem to need it, but this would open things up for earlier macs. It'd be good to try.
|
|
Posts:
190
Registered:
8/13/12
|
|
|
|
Re: netBOOT ROM driver
Posted:
Nov 28, 2018 11:13 PM
in response to: bbraun
|
|
|
Interesting info, Dan8! Thanks for sharing! Based on the assembly I'm reading, I think the bits in the combo mask are read in reverse order, so 0x18 would mean that it's only enabled for combos 3 and 4. 0x78 means it's enabled for combos 1, 2, 3, and 4. From what I can tell, the AV Macs already default to a combo of 4, so this makes sense.
bbraun, were you testing your IIsi ROM with an actual IIsi, or an older Mac? It looks like the IIsi actually has a default combo of 4, so it should already be loading the netBOOT driver, unless I'm terribly mistaken. But the IIci (and presumably other older Macs) have a default combo of 1 or 2. IIci=1, IIfx=2, for example. So they wouldn't load the netBOOT driver unless their combo was changed in PRAM. Also, combo 4 appears to be "no FPU" but combo 3 means "FPU". If a Mac is listed as combo 4, but it has an FPU, it gets changed to combo 3 at boot.
|
|
Posts:
3
Registered:
12/14/16
|
|
|
|
Re: netBOOT ROM driver
Posted:
Dec 1, 2018 8:05 PM
in response to: dougg3
|
|
|
So it seems that combo 4 is the best choice because it doesn't matter if there is a FPU or not. Most likely to work on anything.
It would be cool to make a netBOOT floppy with a fake system file that just sets the PRAM values, ejects the floppy, and reboots.
The boot server name would probably have to be hardcoded. Maybe have several with different values and use each one to netBOOT a different install image?
|
|
Posts:
3
Registered:
12/14/16
|
|
|
|
Re: netBOOT ROM driver
Posted:
Dec 19, 2018 9:59 PM
in response to: bbraun
|
|
|
It seems that ATBoot wants a very special type of disk image. The image buffer is called as a function several times in the boot process.
The prototype of it would look like OSErr image_code(short command, DGlobals *g, int **var1, int **var2). The command selector selector can take a value of getBootBlocks, getSysVol, or mountSysVol. Apparently var1 and var2 aren't used for anything.
The image code itself is responsible for copying boot blocks into a buffer in the globals passed to it (turns out I was wrong about that. ATBoot confused me). It has to prepare the system volume itself. The NetBoot driver gives control when an external file system _MountVol call is made to the NetBoot drive (NetBoot sets up a code hook. The condition is probably triggered while the boot blocks are being run). The image code is expected to replace the NetBoot driver by itself when this happens, as neither NetBoot nor ATBoot contain actual RAMDisk driver code. I'm not sure if it has to do anything else. I wouldn't be surprised if it did.
This is a crazy complicated piece of code and I believe we have no source or working examples of it. Did Apple ever use this NetBoot feature?
Message was edited by: Dan8
|
|
|
|
