On 12 Feb, Eric W. Biederman wrote: > Tyson D Sawyer <[EMAIL PROTECTED]> writes: >> To get the kernel to recognize that there is an initrd image you must >> set the loader type value in the "empty_zero_page" of kernel >> parameters. Does anyone know about getting a loader ID for linuxbios? >> This might be useful for some kernel paches that are linuxbios >> specific. > > I hadn't thought in that direction and I'd like to avoid it. When you > start chaining boot loaders this information could be lost. Does anyone know what problems we might run into by setting a random or arbitrary loader ID? we have to set something. >> Also, how does the loader ID relate to the kexec method of doing >> things? It was said that kexec allows for passing a command line, but >> can you adjust any of the other kernel parameters that are in the >> empty_zero_page? > > Yes, and no. With the kexec stuff you don't have access to the > empty_zero_page directly. But yes in theory you should have access to > all of that stuff. In practice all that has been implemented is > setting the memory size. So, it is possible to implement any parameter that is needed? > I'm just entering the cleanup/documentation phase myself so I should > be able to help with this. Though I have a presentation to give > in a week and a half and I've been procrastinating getting it ready, > so that is at the top of the priority list. > > I intend to implement the kexec stuff for the alpha, but except for > the actual jump to the loaded kernel it should be the same code for > x86. Any guess on when it would be accessable? I need to decide how much work I should put into this type of stuff before considering a change to kexec. If kexec is really the right way to do things that I'd like to avoid developing a different system first. Question: I had mentioned that combining the initrd image with the kernel into a single elf executable made it difficult to pick from a set of kernels and/or a set of filesystems. Would it make sense to load the filesystem as an ELF non-executable, load the kernel as an ELF executable and make sure it gets the parameters to find the file system? Perhaps it would make more sense to load the initrd image as just a raw image (as I am doing now) and then load the kernel seperately as an ELF? Suggestion: We had discussed organizing the ROM space and being able to search for multiple files and being able to update sections of it. It might be useful to look at using the romfs for this. It is very simple and so long as you "partition" the rom such that each romfs doesn't overlap 64K blocks (or what ever is the block size for the flash in question) you could replace parts of the system. In many cases you might put no more than a single file (such as a kernel image or initrd image) in each romfs but the romfs still offers packaging that is useful such as length and checksum information. This idea came to me as I was trying to figure out how to deal with the length of my initrd image for loading it and giving the needed info to the kernel. romfs is an existing standard that "packages" that information with the initrd image file. Other options where to research a particular 32bit word somewhere in rom that the loader would look at in a hard coded address. I would have to write tools to add this information to the binary rom image. The tools would be trivial but still, I would have to write them and they would be very non-standard. Using existing standard tools is much more attractive to me. Thoughts? Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Real World Interface Div. [EMAIL PROTECTED] Robots for the Real World 603-532-6900 ext 206 http://www.irobot.com
