On 06/04/17 15:56, John Paul Adrian Glaubitz wrote: > On 04/05/2017 10:19 AM, Frans van Berckel wrote: >> If kernel size still >10 Mb, from tftpboot.sh, add sparc* ;-). > > Hmm, I'm not sure whether the kernel is the deciding factor here > but I will give it a try. I need to investigate into this mechanism > a bit more. > > It's a bit odd that OpenFirmware has such weird limitations. I have > known these things from classic x86 PCs but I wouldn't expect that > from a fully-fledged 64-bit system like the Sun Ultra machines. > > Would be good if someone knowledgeable from the Oracle crowd could > chime in. Maybe there are some tricks to work around the limit. > >> But please be sure, and check first, are elftoaout & piggyback64 really >> able handling such an compressed kernel? > > Of course. I'm not going to commit anything without testing it first.
Commenting from an OpenBIOS perspective, the first 10MB or so of RAM is mapped 1:1 phys:virt by the PROM in order to provide space for bootloaders - load-base is set to 0x4000 by default which means anything referenced by "load" or "boot" commands is going to load and execute at this address. Having a quick look at the tilo patches, it looks like they do the right thing which is to take the compressed image obtained via TFTP at load-base, use the PROM to allocate and map the relocated kernel/initrd image memory (from the ELF headers maybe?), then decompress the binary image into the allocated target memory and run it. Note that this means the compressed image is still subject to the 10MB limit, but likely that should be less of a problem these days with compressors such as xz. ATB, Mark.
