Still trying to find a way round the ‘always boot to rom’ conundrum, and the results of my latest test are not looking too positive..
Instead of running the various parameters in the U-Boot environment, I entered the basic commands by hand:

WMT # usb reset
(Re)start USB...
wmt.usb.param: 11:3
usb select port D
scanning bus for devices...
 1 USB Device(s) found
scanning bus for storage devices...
 usb_request_sense
 usb_request_sense
 usb_request_sense
 ..... <repeated> .......
 usb_request_sense
 usb_request_sense
 Device NOT ready
   Request Sense returned 02 3A 00
 usb_request_sense
 usb_request_sense
... <repeated>......
 usb_request_sense
 usb_request_sense
 Device NOT ready
   Request Sense returned 02 3A 00
4 Storage Device(s) found
WMT # root=/dev/sdb2
WMT # rootfstype=ext2
WMT # fatload usb 1:1 0x1000000 uzImage.bin 400000
part_offset : 800, cur_part : 1
reading uzImage.bin
.......................................................................................
.........................................................

2969256 bytes read
WMT # fatload usb 1:1 1400000 initrd.gz 400000
part_offset : 800, cur_part : 1
reading initrd.gz
.......................................................................................
......................................................................

3231913 bytes read
WMT # bootm 0x1000000
## Booting image at 01000000 ...
   Image Name:   Linux-2.6.32.9-default
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2969192 Bytes =  2.8 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux....................................................................
.......................................................................................
....................... done, booting the kernel.

Then the main console on the monitor displayed a Kernel panic:

.............
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00        13312 mtdblock0 (driver?)
1f01         2560 mtdblock1 (driver?)
1f02          320 mtdblock2 (driver?)
1f03           64 mtdblock3 (driver?)
1f04           64 mtdblock4 (driver?)
1f05           64 mtdblock5 (driver?)
1f06         1024 mtdblock6 (driver?)
1f07         9216 mtdblock7 (driver?)
1f08         9216 mtdblock8 (driver?)
1f09         8192 mtdblock9 (driver?)
1f0a         6144 mtdblock10 (driver?)
1f0b       262144 mtdblock11 (driver?)
1f0c         2048 mtdblock12 (driver?)
1f0d         4096 mtdblock13 (driver?)
1f0e      1048576 mtdblock14 (driver?)
1f0f       131072 mtdblock15 (driver?)
1f10       615424 mtdblock16 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Backtrace:
[<c00303a8>] (dump backtrace+0x0/0x10c) from [<c0414ac8>] (dump_stcak+0x18/0x1c)
.......... etc .............

This would appear to confirm my previous theory, that the kernel code on the device is set to only boot to ram – in all cases.   If this is correct, then it makes the substitution of a ‘real’ Linux distro filesystem next to impossible.

What is needed is a version of the APC kernel that allows the correct use of the root=/dev/sdb2 parameter to allow the root fs to be resident on the same disk that the system has booted from – as normal..

Of course, the best scenario would be the availability of open-sourced drivers for all the APC components, including the WM8750 system-on-a-chip..   In reality, this process may well take some considerable time.