|
Marc Singer wrote:
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 <eugenesan@gmail.com> [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.
Do you think of single initrd or several for each machine?
What do you expect size of compressed initrd, to be?
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 2.6.26.
4) 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.
Good, if you still need help contact me.
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?
No, that looks strange for me too. Probably one of default parameters
got vanished.
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.
Cheers.
|