On Fri, Apr 19, 2002 at 07:32:09PM +0000, Ryan Underwood wrote: > > BTW: The digital decstations also need 512 byte blocking on the cd - > > This might be impossible to create for todays burners. I'll have to try. > > Please do, and let us know. It seems that some Teac writer: > http://sites.inka.de/pcde/dec-cdrom-list.txt > can read 512 bytes/sector, dont know about writing though. I have a LG DVD/CD-RW combo in this machine - I tried to read the Ultrix 4.4 installation media which is 512byte blocked too - I had no problems copieing to disk with xcdroast - The next thing i tried is to put a "boot-sector" into an iso image - Means - The Decstation expects the first 512 byte of a disk/cdrom/tftpdownload to be some kind of boot-sector where the list of blocks to read for the kernel/boot-loader is mentioned. I just copied the first 512 bytes into a "test" iso i quick created. I then mounted it with loop mode to see whether the kernel gets irritated by the "abnormal" bytes in the first 512 byte. It seems the kernel ignores those bytes which means it should really trivial to get bootable decstation cds. I dont know much about multi-session stuff and how this might help with the sgis - It might simple work to put the tftpimage into a volume header like on disk and burn that into the first session of a cd - The sgi might think its a disk and load the tftpimage - Now the kernel needs to know to ignore the first session - I dont know how to do this. From my reading about multi-session stuff the kernel is usually overlaying all sessions to a single filesystem. But what happens if one of the sessions is NOT an iso9660 ? While looking at the content of a sgi cdrom i find this: 0x00000000: 0BE5A941 00000000 00000000 00000000 .å©A............ 0x00000010: 00000000 00000000 00000000 6ECE0000 ............nÎ.. 0x00000020: 00010000 00000020 02000000 00000034 ....... .......4 0x00000030: 00000000 00000000 00000000 00000000 ................ 0x00000040: 00000000 00000000 7367696C 6162656C ........sgilabel 0x00000050: 00000020 00000200 696F3470 726F6D00 ... ....io4prom. 0x00000060: 00000021 0005E5B8 6D720000 00000000 ...!..å¸mr...... 0x00000070: 00000314 01760C00 73617368 2E495034 .....v..sash.IP4 0x00000080: 0000BE1A 00033E90 73617368 2E495035 ..¾...>.sash.IP5 0x00000090: 0000BFBA 0003A9D0 73617368 2E495036 ..¿º..©Ðsash.IP6 0x000000A0: 0000C18F 00031CD0 73617368 2E495037 ..Á....Ðsash.IP7 0x000000B0: 0000C31E 0003A9D0 73617368 2E495039 ..Ã...©Ðsash.IP9 0x000000C0: 0000C4F3 0003A9D0 73617368 41524353 ..Äó..©ÐsashARCS 0x000000D0: 0000C6C8 000236C4 73617368 49503132 ..ÆÈ..6ÄsashIP12 0x000000E0: 0000C7E4 0003CE40 73617368 49503137 ..Çä..Î@sashIP17 0x000000F0: 0000C9CC 00043B40 00000000 00000000 ..ÉÌ..;@........ 0x00000100: 00000000 00000000 00000000 00000000 ................ 0x00000110: 00000000 00000000 00000000 00000000 ................ 0x00000120: 00000000 00000000 00000000 00000000 ................ 0x00000130: 00000000 00000000 00000000 00000000 ................ 0x00000140: 00000000 00000000 00000000 00000000 ................ 0x00000150: 00000000 00000000 00000000 00000000 ................ 0x00000160: 00000000 00000000 00000000 00000000 ................ 0x00000170: 00000000 00000000 00000000 00000000 ................ 0x00000180: 00000000 00000000 00000000 000CED50 ..............íP 0x00000190: 0000EC60 00000005 0000EC60 00000000 ..ì`......ì`.... 0x000001A0: 00000000 00000000 00000000 00000000 ................ 0x000001B0: 000DD9C0 00000000 00000006 00000000 ..ÙÀ............ 0x000001C0: 00000000 00000000 00000000 00000000 ................ 0x000001D0: 00000000 00000000 00000000 00000000 ................ 0x000001E0: 00000000 00000000 00000000 00000000 ................ 0x000001F0: 00000000 00000000 0D09C430 00000000 ..........Ä0.... 0x00000200: 00000000 00000000 00000000 00000000 ................ These are the very first 512 bytes of this cd - It looks like a volume header which means the same "hack" as on the decstations should be possible. Letting the prom think it has a "disk" with a volume header at the beginning but in reality it loads the kernel from an iso9660 filesystem which works because files should be contiguos on an iso9660. After the kernel comes up we are able to read common iso9660. Which means in the iso build process we create the normal cdroms - Then loop mount it - get the block layout with the "fibmap" ioctl (look at lilo or delo on how to do this), umount the iso and rewrite the first 512 bytes of the iso with the informations on the fibmap ioctl. (I am unshure on how big the volume header meta informations are, but from looking at a test iso i find the informations start at 0x8000 and the sgi "binary" data starts at 0x4200 which should give us enough room) From guessing we can ignore the 512 vs 2048 byte block issue. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium
Attachment:
pgp69HFHjcBMJ.pgp
Description: PGP signature