| OK, it's an issue with the block size/frag size of the miniroot.
| The miniroot is built with bsize=16k,fsize=2k
| I hacked the Makefiles to build the miniroot with the default bsize/fsize
| (I had to bump it to 14M to have enouth inodes) and the resulting miniroot
| boots.
|
| The best is probably to teach bootblk to handle the bsize/fsize stored in
| the superblock properly, but as a workaround changing Makefile.instfs
| to use 8k/1k may be enouth (need to tweak other makefs options to have enouth
| indodes, though).

I have also found problems with the cross-generated boot
blocks.  I don't know how far it extends, but I know that
load-file-print-size, is corrupt.  The source is:

: load-file-print-size ( size -- size )
   ." Loading" space dup . space ." bytes of file..." cr 
;

The decompiled FCode from a good boot block is:

: load-file-print-size   
   " Loading" type bl emit dup . bl emit " bytes of file..." type 
   cr 
; 

The decompiled FCode from a recent nightly build is:

: load-file-print-size   
   " Loading" type bl emit dup 0 bl emit " bytes of file..." type 
   cr 
; 

The first version prints a string, then prints the top of the stack,
then prints a string.  The second version prints a string, puts a
0 on the top of the stack, then prints a string.  This may be one
source of the warnings about stack depth changes.  

This specific routine is debug only, so it is innocuous unless
the `-V' flag is specified.  However, if this is happening in
other parts of the bootblock it could easily cause problems
loading 16K/2K filesystems.

Eduardo