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 +, Chris
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
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() fu
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, 0x30 virt)...
Data Access Exc
It branches to "trap_setup" which is what sets
up %g6 via the LOAD_CURRENT() macro we discussed
earlier.
Thanks, I found the bug: PS flag was always equal to S, so %g6 was assumed
OK. Now we reach the userland:
RAMDISK: Loading 64KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesys
