Writing file system with U-Boot

In http://elinux.org/BeagleBoardNAND#File_system Dirk reported that

"A lot of users report they have issues with writing (root)
  file system with U-Boot" (oct 2008)

but I couldn't find much more about the subject.

OTOH, U-Boot's doc/README.nand states that:

"The current NAND implementation is based on what is in recent
  Linux kernels" (april 2009)

which kind of suggest that the problem should be fixed now.
Unfortunately this does not seem to be real, as I can burn both
U-boot and the kernel using U-boot itself, but not a (working)
JFFS2 image.

The questions:
* the issues mentioned in the wiki are Beagle-specific,
   OMAP-specific, or related to U-Boot's NAND management in
   general;
* they are considered a bug (perhaps reported, maybe being
   worked on) or just something that nobody really cares about;
* any pointers to more info?

For completeness, the symptoms for me are the following.

I've written in NAND (via serial port):
* U-boot (omap3_beagle_config, with CHSETTINGS and CHRAM)
* Linux kernel (omap3_beagle_defconfig)

and Linux starts fine.
Then I prepared a small root filesystem with busybox and
almost nothing else, and wrote it in NAND after erasing the
fs partition with 'nand erase clean ...'.

When trying to boot with the newly written fs I get:

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc6-07695-g4fa42e4-dirty (murray@gromit) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #4 Thu Feb 18 15:22:58 CET 2010
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mtdblock4 rw rootfstype=jffs2
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB 128MB = 256MB total
Memory: 255872KB available (3300K code, 295K data, 124K init, 0K highmem)
...
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
VFS: Mounted root (jffs2 filesystem) on device 31:4.
Freeing init memory: 124K
Kernel panic - not syncing: Attempted to kill init!
INFO: RCU detected CPU 0 stall (t=1280 jiffies)

However if I set init=/usr/bin/yes it works (without
reflashing anything):

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc6-07695-g4fa42e4-dirty (murray@gromit) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #4 Thu Feb 18 15:22:58 CET 2010
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mtdblock4 rw rootfstype=jffs2 init=/usr/bin/yes
...
regulator_init_complete: incomplete constraints, leaving VDAC on
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
VFS: Mounted root (jffs2 filesystem) on device 31:4.
Freeing init memory: 124K
y
y
y
y
...

Luca