[EMAIL PROTECTED] writes:
> 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.
Agreed. In my mkelfImage script I'm hard coding it to something I think 5.
> >> 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?
Yes. The format is designed to be expandable. Execpt for the command line
I try and keep the options down to those things that are simply not probeable.
> > 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.
O.k. As far as implementation in linuxBIOS written by me I wouldn't
count until I return from the Extreme Linux Developers Forum next
week. Preparing my presentation, is my current priority. After that
I'm in stabalization cleanup mode. With no particular pririties yet
except to get all of this stuff done. However memcpy and jmp are
fairly easy to implement. With the alpha stuff I am current passing
the current arguments, and I could probably just cut & past the code
from there. So on the loader side it's not hard and the image builder
already exits. For x86 I am currently cheating and reusing the linux
compression but that change.
> 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?
I've been thinking about this a little. To handle some of the cases
it might make sense to set root=/dev/mtd0, and at least set up the rom
driver so you can have a file system in your rom.
For the case when you can only afford a kernel and a ramdisk, putting
them all together into one ELF image is failry optimal. For the case
when you have pletty of disk space on a hard drive the slight excess
doesn't matter.
The only case that really matters is when you ample but limited room
in a flash chip. For now I'm going to seriosly suggest the /dev/mtd
approach to working with my stuff.
I'm willing to play with other ideas until we get this case handled
right, the design is so clean and trivial now on the loader side I
would hate to have to complicate it.
Of course there is the totally wacked idea of using interlaced
elfImages, and force a ramdisk sharing that way. Totally wacked but
possibly worth a look.
What are the requirements of your application. Sometimes it helps to
design for specific cases instead of general ones.
> 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?
Sounds good. I haven't looked at the actual format of romfs.
The only real thing I can suggest is getting a working /dev/mtd.
It's fun to flash your rom on a working system. And with a little
care that might solve some of the issues.
Eric
