Marc Singer wrote:
Do you think of single initrd or several for each machine?On Tue, Jun 10, 2008 at 08:23:25PM +0200, Martin Michlmayr wrote:Eugene, let me introduce you to Marc Singer. He recently started working on Debian support for the HP mv2120. Marc, Eugene is interested in Debian support too. Eugene seems to know a lot about the boot process. My answers are inline below (but maybe we should move this discussion to debian-arm for all to see?):Good plan.* Eugene San <firstname.lastname@example.org> [2008-06-02 08:15]:Hi, Few questions first: 1) How exactly install images created in Debian? Is there any special automatic procedure or they just created and uploaded by maintainer?There's a project called "debian-installer" which puts all the installer components together. It also generates the actual installer image.2) Runtime initrd and kernel, is their build and usage procedure is forced by some kind policy or/and automatic procedure? Can we change that? Let's say, run that machine without initrd and use uImage instead of standard image?The initrd is generated by initramfs-tools. We can change some things... but there are some limits to what we can change because other machines have different requirements, and we have to use one kernel on all Orion based devices.I believe we're going to have to generate a uImage to get the system to boot without replacing uBoot in flash. Sure. We should be able to use the same kernel on all machines as long as we can perform a post-install hook to cope with the initramfs binding, or whatever.
What do you expect size of compressed initrd, to be?
Good, if you still need help contact me.3) Can we inject mv21xx/51xx support now or will have to wait for 2.6.27 to land in SID?Yes. In fact, we have Orion support in Debian sid already. 2.6.25 in sid has support for the mv2120 included. At the moment, the mv2120 patch is not included in the Debian 2.6.26 patch... but I can include it once someone backports the 2.6.27 patch to 126.96.36.199) Is install procedure of that kind of devices is automatic to avoid use of RS232? How set of packages and partitioning is controlled?Right, to avoid the need for a serial install. The installer includes a partitioner, so you can choose how to partition it... you can also choose which packages to install.I've been working on a tool to leverage the RCVR recovery function in uBoot to bootstrap the install process. This will allow us to run the installer without opening the box. I am catching the beacon and starting the TFTP transfer. I should have something working in a few days that can upload an image.
No, that looks strange for me too. Probably one of default parameters got vanished.I don't think initrd can be part of regular boot without uBoot environment modifications, but I think there is userspace utility that can help.Marc has some ideas on this.1) Use a multipart uImage to load kernel and ramdisk. I don't know if uBoot supports this, but it is in their format. This requires construction of a custom uImage in the kernel install post-hook. 2) Use a singlepart uImage with an initramfs appended to the kernel. This requires that we prepare this special kernel as part of building the kernel install post-hook. 3) Use either a kernel shim or APEX to perform fixups. This would be prepended to the kernel image and run automatically and is yet another special step on kernel image install. 4) Last, do a complete port of APEX that can read from the hard drive and use APEX to load the kernel and ramdisk from the hard drive. This requires the most new work, so I'm hoping that one of the other options works and we don't have to take this tack.Can you describe the recovery procedure? Do you know how it works? Because I don't think I know exactly how it works.First, I have some knowledge of the recovery procedure. If you need to know more, just ask ;-) After recovery mode initialized, by holding front reset while powering up or invoking "rcv" in uBoot: 1) uBoot starts dhcp client. If that fails it selects defined in uBoot recovery IP. 2) Waits for client to authorize and then waits for TFTP upload from clientside. First 2M reserved for kernel uImage, the rest is uInitrd image. 3) uBoot has it's own treatment for combined images. uBoot unpacks both images into RAM and initiate regular linux+initrd boot. Tool called mkimage, which is part of uBoot source can be easily disintegrated into 3 separate source files, is used to create such images. uBoot just wraps regular zImage and zInitrd with special header. 4) We can use original recover tool, but it exists only for windows.I think Marc will find this info useful. Eugene, do you know howto produce such a rescue image?This matches what I've found so far. Thanks. One thing that is really odd, though. I found yesterday that holding the reset button while powering the device on is no longer running the recovery procedure automatically. I cannot explain why. I may need to perform a complete recovery of the system to put it back into the factory default setup. Eugene, have you ever seen this behavior?
You may invoke "rcvr" start recovery procedure or alternately invoke "resetenv; reset;" to restore uBoot defaults.
Hope "resetenv" is implemented in your version of uBoot.