Re: Patch: SILO/first-isofs/isofs.c (Fix Sun4c)

Re: Patch: SILO/first-isofs/isofs.c (Fix Sun4c)

[Ben Collins]

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 ?
> 

> --- silo-1.4.8/first-isofs/isofs.c.orig	2005-02-22 13:26:47.000000000 +0000
> +++ silo-1.4.8/first-isofs/isofs.c	2005-02-22 16:31:01.000000000 +0000
> @@ -68,7 +68,7 @@
>  		*s++ = (ap->boot_dev_ctrl & 07) + '0';
>  		*s++ = ',';
>  		// Hopefully it's never > 10
> -		*s++ = ap->boot_dev_unit;
> +		*s++ = (ap->boot_dev_unit & 07) + '0';
>  		*s++ = ','; 
>  		*s++ = '0';
>  		*s++ = ')';


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Patch: SILO/first-isofs/isofs.c (Fix Sun4c)

[Chris Newport]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]


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 ?


[-- Attachment #2: isofs.patch --]
[-- Type: text/plain, Size: 371 bytes --]

--- silo-1.4.8/first-isofs/isofs.c.orig	2005-02-22 13:26:47.000000000 +0000
+++ silo-1.4.8/first-isofs/isofs.c	2005-02-22 16:31:01.000000000 +0000
@@ -68,7 +68,7 @@
 		*s++ = (ap->boot_dev_ctrl & 07) + '0';
 		*s++ = ',';
 		// Hopefully it's never > 10
-		*s++ = ap->boot_dev_unit;
+		*s++ = (ap->boot_dev_unit & 07) + '0';
 		*s++ = ','; 
 		*s++ = '0';
 		*s++ = ')';

Re: Patch: SILO/first-isofs/isofs.c (Fix Sun4c)

[Chris Newport]

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 ?
>>
>>    
>>

Re: Patch: SILO/first-isofs/isofs.c (Fix Sun4c)

[Ben Collins]

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/