Probably the memory_find() function in second/memory.c. Put some debug in there for latest silo, and recompile an older silo with the same debug. See if you can find differences for the initrd_start value, and the beg value returned by memory_find().
On Wed, Feb 23, 2005 at 01:00:19AM +0000, Chris Newport wrote: > I was getting too bogged down in the second/ code so I tried > simply using the second.b from older versions. > > second.b from silo 1.2.6 works fine on all sun4c and sun4m > but fails on sun4u > second.b from silo 1.4.5 and 2.4.8 both screw up on sun4c > > So it looks like the sun4c / prom v0 support got broken between > 1.2.6 and 1.4.5 > > Does this point to any smoking guns ?. > > Ben Collins wrote: > > >Thanks. Committed to the repo. I'll try to get a new version out soon. > > > >As for the next error, it looks like it is trying to load it to the > >physical address of 0x0, which is a bad thing. That overwrites silo > >itself. > > > >So I guess there is an error in silo (not first-isofs). Check the > >memory_find() function in second/memory.c and see why it is using a > >physical address of 0x0. > > > >On Tue, Feb 22, 2005 at 04:55:10PM +0000, Chris Newport wrote: > > > > > >>This small patch fixes silo-1.4.8/first-isofs/isofs.c > >>Copying an int into a string is not a good idea. > >> > >>Sun4c now loads second.b and the kernel, but still > >>barfs loading the initrd. > >> > >>boot: > >>Loaded kernel version 2.4.27 > >>Loading initial ramdisk (905216 bytes at 0x0 phys, 0x300000 virt)... > >>Data Access ExceptionType b (boot), c(continue), or n (new command mode) > >> > >> > >>Does anyone know what is wrong here ? > >> > >> > >> > -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
