Difference between revisions of "Netboot image creation for SPARC machines"
(→Limitations) |
(→Limitations) |
||
| Line 28: | Line 28: | ||
* sun4u machines (e.g. UltraSPARC I/II/III/IV servers and workstations) do not initialize the processor MMU and thus, '''this ''requires'' the whole netboot image to fit within 4 megabytes'''. What happens if this rule is enforced? Simple: as the buffer where the netboot image is loaded into acts as a 4 megabytes ring-buffer, any byte exceeding the limit will overwrite the previously netboot image loaded data leading to the so famous "Fast Data Access MMU Miss" a couple os seconds after the machine started to download the netboot image. | * sun4u machines (e.g. UltraSPARC I/II/III/IV servers and workstations) do not initialize the processor MMU and thus, '''this ''requires'' the whole netboot image to fit within 4 megabytes'''. What happens if this rule is enforced? Simple: as the buffer where the netboot image is loaded into acts as a 4 megabytes ring-buffer, any byte exceeding the limit will overwrite the previously netboot image loaded data leading to the so famous "Fast Data Access MMU Miss" a couple os seconds after the machine started to download the netboot image. | ||
| − | * sun4v machines (e.g. UltraSPARC T1 and later) initialize their MMU and thus, are not subject to the above limitation. Pay attention to the startup messages when you power on the machine you will see something like "MMU | + | * sun4v machines (e.g. UltraSPARC T1 and later) initialize their MMU and thus, are not subject to the above limitation. Pay attention to the startup messages when you power on the machine you will see something like "Init MMU init" (assuming you are connected to the virtual console from ALOM). |
<pre> | <pre> | ||
Revision as of 12:11, 16 February 2011
If your SPARC machine has a dead CD/DVD ROM drive or no CD/DVD ROM drive at all or if, for various reasons, you wish to build a netboot image from scratch the following paragraphs should help you.
Concepts
Basically, a netboot image is the sum of :
- Some bootstrap code (loader)
- An uncompressed kernel image
- An optional ramdisk / initrd image.
When the machine is powered-on, a Power On Self Test (POST) of the machine is done then, if nothing has been found defective Open Boot checks what the variable boot-device look like and take appropriate actions. If the machine has been set to boot via the network several situations can happen :
- if Open Boot has no WAN boot (Open Boot prior 4.17.1 ?) support and no DHCP support, a RARP request is emitted on the network to get an IP address from a RARP server then the machine starts a TFTP session on the machine who provided the IP and request to download a file named after the provided IP address (e.g. 192.168.4.101 => C0A80465).
- if Open Boot has been set to boot from the network using a DHCP request (boot-device is set to net:dhcp or boot net:dhcp has been entered at the Open Boot prompt), the machine will grab its network parameters using a DHCP request then starts to download the file according the DHCP response (filename and TFTP server), or by default adopt the same behavior than above.
- if Open Boot has been setup to perform a WAN boot, it uses what is contained in the variable network-boot-arguments to determine what to download from which location and with what networking parameters.
Once the netboot image has been downloaded, Open Boot transfers the execution the netboot image loader, which, at its turn will transfer to the Linux kernel which will run /sbin/init (or whatever else specified through the kernel command line). On most of the Funtoo machines in the world, /sbin/init will launch Open RC at the end do various things.
Short story : OpenBoot -> Netboot loader -> Linux kernel -> /sbin/init -> Open RC -> Login on a tty or
The process is very similar to what happens when booting the machine from its hard drive, nothing magic here. The form varies, but the philosophy remains the same.
Limitations
According to various sources on the internet and experience returns, it looks like that :
- sun4u machines (e.g. UltraSPARC I/II/III/IV servers and workstations) do not initialize the processor MMU and thus, this requires the whole netboot image to fit within 4 megabytes. What happens if this rule is enforced? Simple: as the buffer where the netboot image is loaded into acts as a 4 megabytes ring-buffer, any byte exceeding the limit will overwrite the previously netboot image loaded data leading to the so famous "Fast Data Access MMU Miss" a couple os seconds after the machine started to download the netboot image.
- sun4v machines (e.g. UltraSPARC T1 and later) initialize their MMU and thus, are not subject to the above limitation. Pay attention to the startup messages when you power on the machine you will see something like "Init MMU init" (assuming you are connected to the virtual console from ALOM).
... 0:0>VBSC selecting POST MIN Testing. 0:0>POST enabling threads: ffffffff 0:0>VBSC setting verbosity level 2 0:0>Start Selftest..... 0:0>Master CPU Tests Basic....Done 0:0>Init MMU..... ...
Fortunately for us : SPARC machines relies on a very small set of hardware from an model to another (modulo extension cards). Unfortunately for us : 2.6 kernels, tends to be big even with an aggressive strip down of features and aggressive size optimizations.
=
