Re: HP mv2120 support in Orion tree

[Marc Singer <elf@buici.com>]

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.

> > 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.

> > 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?

Cheers.