Hey ChumbyLurker, I may be incorrect in this but is the Infocast's kernel handled in the same fashion as the C1? I ask because after getting a kernel recompiled with a different build number I was unable to get the system to actually recognize it.
I found that the silvermoon update.sh worked just like the C1 with its use of the config_util and I dug through that and got a grasp on how the partitioning and flags worked. I checked the offsets for krnA and krnB by doing a hexdump of the partition and saw the byte pattern of the zImage in each area.
I used putblock, set the updating flag to 0, did a few sync operations, and rebooted but it was still the same build that came up. After a bit I decided to try to see if I was having any influence with writing to those areas and piped /dev/zero over krnA and krnB. The overwritten areas persisted a reboot and I still had a working kernel. Is the kernel pulled from elsewhere of a checksum fails or in the event that it looks as though a failure has occurred? U-Boot in the partition was definitely having an influence, though, when I modified that .
At that point I started to look at the /boot/vmlinuz file, but I really haven't made much headway with having a custom kernel that the device would actually boot to.