Using APEX and a second stage loader for MV2120.

[Marc Singer <elf@buici.com>]

I've finished the basic work to use APEX as a second-stage boot loader
for the orion5x (mv212).  My timing tests show that APEX will boot
substantially faster than uboot for two reasons.

 1) APEX reads from SATA much faster that UBOOT.  I'm not sure what
    UBOOT is doing since the APEX code is very simple; it uses the ATA
    compatibility registers.

 2) APEX reads and verifies the uImage in one pass.  Instead of
    reading it into memory, checking the CRC, and then doing a copy,
    APEX does the whole process in one pass.  This also makes the
    memory layout more obvious since we don't have to track where
    things go in memory before choosing a load address for the image.

As a control, uboot takes about 7 seconds to read, verify, and load a
uImage from the disk as shipped.

Timing with newly formatted ext3 partition.  The ext3 format on new
disks seems to cause trouble for uboot as you cansee in the first
column.  uImage is the stock kernel image as shipped.  uImage-big is
an image that bears a kernel and an initrd.  The set of numbers in
parenthesis come from enabling the MMU and cache in APEX.  Note that
the apex image load command is the one that reads, verifies, and loads
the image in one pass.

   	       	uboot ext2load	apex copy	apex image load
uImage		35s	     	4s (2s)     	8s (2s)
uImage-big	111s		9s (3s)		22s (3s)

Yeah, it's a big difference.  Even with the time it takes to load APEX
from disk before loading the Linux kernel, it's much faster.

There are a couple of niggling issues:

  1) I'd like to store the APEX environment in flash so that we can
     modify the way the system boots from user-space.  My nor flash
     driver isn't yet working properly.

  2) In order to get the kernel to boot, I had to add a custom ATAG.
     The thing about this tag is that none of the kernel patches I've
     gotten for the mv2120 refer to it and the stock kernel won't boot
     without it.  What is even wierder is that that only thing the
     kernel cares about is that the UBOOT version number field of the
     ATAG is set.  The rest of the parameters could be zero and it runs
     fine.

So, do we have a bonafide patch from Marvell?  The one on the HP site

  ftp://ftp.hp.com/pub/information_storage/software/MediaVault-opensrc.tar.gz

doesn't appear to make mention of this.  The magic number is
0x41000403.

Cheers