Re: [Fwd: Problem with Install Kernel for Kurobox Pro]

Ken Hornstein wrote:
> So at a first glance I would say that the problem is with the process that
> builds the ramdisk image, since from the errors you post it looks like
> you have a corrupted ramdisk image.
>
> It might be useful to go to src/distrib/evbarm/instkernel and run
> nbmake-evbarm (from tools/bin) and watch very carefully the process
> where the ramdisk is created; the key tool is makefs (nbmakefs in
> tools/bin).  I would guess that there is a problem with this tool under
> Cygwin.  You could set some bits in the debug mask and run it by hand
> to perhaps glean some insight.  At the very worst, you might have to
> hunker down with the makefs sources and figure out what's wrong, if
> you really want to solve it.
>
> You could always take the ramdisk.fs image from the Linux system
> and use it on the Cygwin system; the only problem is that from what
> I see the ramdisk filesystem is always rebuilt by default.  It looks
> like there is some logic in the Makefile to prevent that, but I'm
> not sure if it's disabled or simply not working; you might have to
> do some hacking around to get it to always use your prebuilt ramdisk
> image.
>
> --Ken
>   
Thanks for the reply.  Your suggestions are good ones and I'll give them 
a shot.  I guess I get to learn a lot more about building NetBSD than I 
originally anticipated. :-)

The fact that there is a problem like this surprises me a little, since 
Cygwin has been around a long time and is relatively mature.  Of course, 
Cygwin has always had to deal with the Unix/Windows incompatibilities 
like upper-case/lower-case file names.  I had (or still have) a fear 
that I did something like unintentionally edit a file with a Windows 
program that would put a <CR> into a file that is the cause a problem.  
But I haven't found anything like that yet.  I did copy the src tree 
from Win to Linux to insure that the kernels were built from the same 
source - the only thing I found was a directory on the Win side that was 
upper-case letters (DB vs db).

A cursory byte-for-byte comparison of the two ramdisk.fs files shows 
that they are mostly the same, but not identical.  It's difficult to 
draw many conclusions without detailed knowledge of the file structure, 
but there were two easily spotted differences.  The first is a 
frequently occuring four byte sequence that is close but not exactly the 
same, which I'm guessing is a date code.  The second is that the 
apparent meat of the memory disk starts 512 bytes sooner in the Cygwin 
version.  If this rings a bell with anybody, please let me know.

Otherwise, I suppose I'll put away this tiny little shovel I have and go 
out and rent me a backhoe, because I have some serious digging to do.

Regards,
Don