Re: [PATCH] sparc: fix compile failure ("struct resource" related)

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Andrew Morton]

Alexey Dobriyan <adobriyan@mail.ru> wrote:
>
> Signed-off-by: Alexey Dobriyan <adobriyan@mail.ru>

Thanks.  Many of these fixups are due to a 64-bit-resource patch in Greg's
bk-pci tree which he has now reverted.  That being said:

- That patch will come back sometime

- Fixes like the below make sense anyway and can be merged any time.

- All the fixes which were only applicable when the 64-bit-resource patch
  is present have been sent to Greg for when that patch reemerges.


> --- linux-2.6.11-rc5-mm1/arch/sparc/kernel/ioport.c.orig	2005-03-01 21:11:30.000000000 +0200
> +++ linux-2.6.11-rc5-mm1/arch/sparc/kernel/ioport.c	2005-03-01 21:12:48.000000000 +0200
> @@ -54,11 +54,11 @@ static void _sparc_free_io(struct resour
>  
>  /* This points to the next to use virtual memory for DVMA mappings */
>  static struct resource _sparc_dvma = {
> -	"sparc_dvma", DVMA_VADDR, DVMA_END - 1
> +	.name = "sparc_dvma", .start = DVMA_VADDR, .end = DVMA_END - 1
>  };
>  /* This points to the start of I/O mappings, cluable from outside. */
>  /*ext*/ struct resource sparc_iomap = {
> -	"sparc_iomap", IOBASE_VADDR, IOBASE_END - 1
> +	.name = "sparc_iomap", .start = IOBASE_VADDR, .end = IOBASE_END - 1
>  };
>  
>  /*

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Andrew Morton]

Alexey Dobriyan <adobriyan@mail.ru> wrote:
>
> Signed-off-by: Alexey Dobriyan <adobriyan@mail.ru>

Thanks.  Many of these fixups are due to a 64-bit-resource patch in Greg's
bk-pci tree which he has now reverted.  That being said:

- That patch will come back sometime

- Fixes like the below make sense anyway and can be merged any time.

- All the fixes which were only applicable when the 64-bit-resource patch
  is present have been sent to Greg for when that patch reemerges.


> --- linux-2.6.11-rc5-mm1/arch/sparc/kernel/ioport.c.orig	2005-03-01 21:11:30.000000000 +0200
> +++ linux-2.6.11-rc5-mm1/arch/sparc/kernel/ioport.c	2005-03-01 21:12:48.000000000 +0200
> @@ -54,11 +54,11 @@ static void _sparc_free_io(struct resour
>  
>  /* This points to the next to use virtual memory for DVMA mappings */
>  static struct resource _sparc_dvma = {
> -	"sparc_dvma", DVMA_VADDR, DVMA_END - 1
> +	.name = "sparc_dvma", .start = DVMA_VADDR, .end = DVMA_END - 1
>  };
>  /* This points to the start of I/O mappings, cluable from outside. */
>  /*ext*/ struct resource sparc_iomap = {
> -	"sparc_iomap", IOBASE_VADDR, IOBASE_END - 1
> +	.name = "sparc_iomap", .start = IOBASE_VADDR, .end = IOBASE_END - 1
>  };
>  
>  /*

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[William Lee Irwin III]

On Tue, Mar 01, 2005 at 01:44:40PM -0800, Andrew Morton wrote:
> Thanks.  Many of these fixups are due to a 64-bit-resource patch in Greg's
> bk-pci tree which he has now reverted.  That being said:
> - That patch will come back sometime
> - Fixes like the below make sense anyway and can be merged any time.
> - All the fixes which were only applicable when the 64-bit-resource patch
>   is present have been sent to Greg for when that patch reemerges.

Well, in isolation it's a C99 initializer cleanup, which is good.

Acked-by: William Irwin <wli@holomorphy.com>


-- wli

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[William Lee Irwin III]

On Tue, Mar 01, 2005 at 01:44:40PM -0800, Andrew Morton wrote:
> Thanks.  Many of these fixups are due to a 64-bit-resource patch in Greg's
> bk-pci tree which he has now reverted.  That being said:
> - That patch will come back sometime
> - Fixes like the below make sense anyway and can be merged any time.
> - All the fixes which were only applicable when the 64-bit-resource patch
>   is present have been sent to Greg for when that patch reemerges.

Well, in isolation it's a C99 initializer cleanup, which is good.

Acked-by: William Irwin <wli@holomorphy.com>


-- wli

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Dennis Jenkins]

Does this mean that I will be able to successfully
compile a 2.6 kernel using gcc 3.3.5 on my sparc64
gentoo box?  Yeah!

now.. If only I (or someone) could fix the fcal/socal
driver.  I even tried using the socal_asm.h firmware
patch derived from the Solaris 10 "socal" firmware. 
No luck. :(

--- William Lee Irwin III <wli@holomorphy.com> wrote:

> On Tue, Mar 01, 2005 at 01:44:40PM -0800, Andrew
> Morton wrote:
> > Thanks.  Many of these fixups are due to a
> 64-bit-resource patch in Greg's
> > bk-pci tree which he has now reverted.  That being
> said:
> > - That patch will come back sometime
> > - Fixes like the below make sense anyway and can
> be merged any time.
> > - All the fixes which were only applicable when
> the 64-bit-resource patch
> >   is present have been sent to Greg for when that
> patch reemerges.
> 
> Well, in isolation it's a C99 initializer cleanup,
> which is good.
> 
> Acked-by: William Irwin <wli@holomorphy.com>
> 
> 
> -- wli
> -
> To unsubscribe from this list: send the line
> "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 


==Dennis Jenkins

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Chris Newport]

Dennis Jenkins wrote:

>Does this mean that I will be able to successfully
>compile a 2.6 kernel using gcc 3.3.5 on my sparc64
>gentoo box?  Yeah!
>
>now.. If only I (or someone) could fix the fcal/socal
>driver.  I even tried using the socal_asm.h firmware
>patch derived from the Solaris 10 "socal" firmware. 
>No luck. :(
>  
>
First check if you should be using the soc or socal drivers.
A handbook search at sunsolve for the barcode on your board will
tell you if it is FC/25 or FCAL - just take the first 7 chars and insert
a dash like this 501-1234.  The  SSA1xx  arrays with 3 pull-out drawers
each containing 10 drives need the soc card and drivers. Later arrays 
such as the A5000 need the socal card and drivers.

The soc/pluto stuff has not been maintained since 2.2.x and AFAIK this 
is also true for socal.

Take a look at http://www.splack.org/fibrechan.html for the lowdown on
how to get soc working on 2.2.x, once you have that working it should
be possible to port the existing drivers to 2.4 and then 2.6.

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Dennis Jenkins]

Thank you for your response!  Details below.

ps- I'm at work.  My box is at home.  The details
given below are from memory.

My box specs: 8 processor E3500 (336MHz), 10G ram, 8x
18.2G fiber channel drives in the 3500 chassis, and an
external A3500 raid array with 35x 9.1G scsi disks.
Linux can see the A3500, but I had to use Solaris to
configure the raid array initially.  It came with 40
drives, but 5 are bad. :(

I added one 18.2G scsi drive on the same channel as
the CDROM (I have Linux on this one).  Openboot prom
can boot Linux (gentoo, kernel 2.4.29) and Solaris 10
successfully.

I picked up my box from a company that was going out
of business.  They had no idea what it was worth.  I
spent much less than $500 for the whole thing.

--- Chris Newport <crn@netunix.com> wrote:
> First check if you should be using the soc or socal
> drivers.
> A handbook search at sunsolve for the barcode on
> your board will
> tell you if it is FC/25 or FCAL - just take the
> first 7 chars and insert
> a dash like this 501-1234.  The  SSA1xx  arrays with
> 3 pull-out drawers
> each containing 10 drives need the soc card and
> drivers. Later arrays 
> such as the A5000 need the socal card and drivers.

socal.  I don't remember how I determined this, but I
did read the documents on the difference between "soc"
and "socal".  The system is definitely NOT an FC/25.

"probe-fcal-all" from openprom sees all 8 drives.  I
have Solaris 10 installed on the first drive.

> The soc/pluto stuff has not been maintained since
> 2.2.x and AFAIK this 
> is also true for socal.

Yup, I read that too.  And immediately there after I
downloaded the last 2.2 kernel and tried to compile
it.  Unfortunately for me, GCC 3.3.5 choked heavily on
it.  I will try again when I figure out how to get
Gentoo to downgrade gcc.  The question is, what
version should I downgrade to?

> Take a look at http://www.splack.org/fibrechan.html

Thanks for the URL!  I will try that procedure soon.

> for the lowdown on
> how to get soc working on 2.2.x, once you have that
> working it should
> be possible to port the existing drivers to 2.4 and
> then 2.6.

I figured that if I could get the socal drive working
on 2.2.x, then I could try to port the changes to 2.4.

I extracted the socal firmware from Solaris 10.  I
then used a perl script (someone else wrote it) to
convert the firmware into the "socal_asm.h" header
file.  I then modified "drivers/fc4/socal.c" to use
the new firmware (in kernel 2.4.29).  This made the
"port A, Port B" error messages go away, but I still
can't see the drives.  Then again, it is known that
socal does not work in the 2.4 series.

My bigger question is, how do I know that I correctly
prepared the socal_asm.h file?  If I post the MD5
checksum of the "socal_ucode" that I extracted from
solaris, can someone here verify that I have the
correct 64K chunk of junk?

I have no idea if I can legally post the first few
lines of the "socal_asm.h" file.  I assume that I can
under the fair use doctrine, but these days..... no
clue.

Thank you for your help.

pss- If someone with more kernel hacking skills than I
wants to try to fix this problem, I'll work with you
to  share my hardware, virtually.  ie, you get root on
the box (it is behind a firewall that monitors inbound
and outbound traffic) and can play away!

psss- This offer is for a legitimate, established,
sparc/linux/kernel programmers whose name and email
address appear in kernel credits or as a trustworthy
individual on this list.  I've never before opened up
any of my boxes to anyone that I did not know
personally.  I don't want my teeny DSL connection used
to commit crimes, etc... :)


==Dennis Jenkins

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Baurzhan Ismagulov]

On Thu, Mar 03, 2005 at 09:19:40AM -0800, Dennis Jenkins wrote:
> Yup, I read that too.  And immediately there after I
> downloaded the last 2.2 kernel and tried to compile
> it.  Unfortunately for me, GCC 3.3.5 choked heavily on
> it.  I will try again when I figure out how to get
> Gentoo to downgrade gcc.  The question is, what
> version should I downgrade to?

Perhaps something like
ftp://ftp.de.debian.org/debian-archive/dists/potato/main/source/devel/egcs64_19980921-4.dsc

However, I don't know which version you need to compile it :) .

With kind regards,
Baurzhan.

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Chris Newport]

Dennis Jenkins wrote:

>>The soc/pluto stuff has not been maintained since
>>2.2.x and AFAIK this 
>>is also true for socal.
>>    
>>
>
>Yup, I read that too.  And immediately there after I
>downloaded the last 2.2 kernel and tried to compile
>it.  Unfortunately for me, GCC 3.3.5 choked heavily on
>it.  I will try again when I figure out how to get
>Gentoo to downgrade gcc.  The question is, what
>version should I downgrade to?
>  
>
I have no idea about Gentoo versions, but Splack 8.0 has a working 2.2 
kernel with soc and socal modules. Everything you need to experiment 
with 2.4 is there, but the toolset and compiler are too old for 2.6
In general, you should not need to have the Sun firmware in your
drivers, just upload them to the card and array from Solaris and they
will stay there in nvram. This avoids contaminating Linux with Sun's code.
The procedure for socal is similar to my procedure for soc, take a look 
at the Solaris man pages for luxadm etc.

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Dennis Jenkins]

--- Chris Newport <crn@netunix.com> wrote:

> I have no idea about Gentoo versions, but Splack 8.0
> has a working 2.2 
> kernel with soc and socal modules. Everything you
> need to experiment 
> with 2.4 is there, but the toolset and compiler are
> too old for 2.6
> In general, you should not need to have the Sun
> firmware in your
> drivers, just upload them to the card and array from
> Solaris and they
> will stay there in nvram. This avoids contaminating
> Linux with Sun's code.
> The procedure for socal is similar to my procedure
> for soc, take a look 
> at the Solaris man pages for luxadm etc.

Ah.  I just did some reading and learned that 'splack'
is a slackware distro for Sparc.  Cool.  I've been
using Slackware for x86 since 1995 (I remember booting
kernel 1.2.13 on a 486sx25 with 2M ram!)  I recently
moved to Gentoo because I like the "portage" thingy. 
Anyway....

I will try booting splack on the box too.  And
flashing the socal drivers, and running "luxadm".

Thank you for your help.  I really do appreciate it.


==Dennis Jenkins

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[David S. Miller]

On Thu, 03 Mar 2005 23:21:15 +0000
Chris Newport <crn@netunix.com> wrote:

> In general, you should not need to have the Sun firmware in your
> drivers, just upload them to the card and array from Solaris and they
> will stay there in nvram.

Not true if you boot from the SOC/SOCAL disks, OBP will load it's
own firmware which is very slow and has tons of debugging enabled
in it.

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Chris Newport]

David S. Miller wrote:

>>In general, you should not need to have the Sun firmware in your
>>drivers, just upload them to the card and array from Solaris and they
>>will stay there in nvram.
>>    
>>
>
>Not true if you boot from the SOC/SOCAL disks, OBP will load it's
>own firmware which is very slow and has tons of debugging enabled
>in it.
>  
>
Oook - that is EVIL.
We really do not want to taint the kernel with Sun's FCode.

I think we could work around this, the OBP is all in FORTH
so we should be able to replace the offending upload function
with a one line null function in nvramrc.
Would this work ?.

Caveat - this theory comes from the decaying memory of a 60
year old Fortran hacker and needs to be properly researched
in the OBP documentation. Significant ForthHackery maybe required.

Re: [PATCH] sparc: fix compile failure ("struct resource" related)

[Dennis Jenkins]

--- Chris Newport <crn@netunix.com> wrote:
> David S. Miller wrote:
> >>In general, you should not need to have the Sun
> firmware in your
> >>drivers, just upload them to the card and array
> from Solaris and they
> >>will stay there in nvram.
> >
> >Not true if you boot from the SOC/SOCAL disks, OBP
> will load it's
> >own firmware which is very slow and has tons of
> debugging enabled
> >in it.
> >  
> >
> Oook - that is EVIL.
> We really do not want to taint the kernel with Sun's
> FCode.

Well, for me, I boot Linux from a normal SCSI drive
attached to the same SCSI channel as the CDROM drive. 
I want to be able to use the FCAL disks for extra
storage (under /mnt/fcal or whatever).  However, I
also want to boot Solaris from time to time.  Solaris
lives on /dev/dsk/c3t0d0s0, the first FCAL drive in my
box.

I don't want OBP or Solaris blasting the FCAL firmware
 with their own private copies.

If we can't hack the forth code, I'm not opposed to
having the Linux kernel load the microcode.  However,
in the interest of keeping the kernel "pure", can we
recode the device driver to load the firmware from a
disk file and not put the firmware directly into the
kernel?  That way the kernel itself won't have Sun's
crap in it.

I realize that there might be a problem if the
SOCAL/FC4/FCAL/whatever driver is compiled into the
kernel and it inializes BEFORE VFS mounts "/"....  For
me, I use "modprobe" to load "socal.[slk]o" on the
fly, so my root FS is already mounted.  Maybe "initrd"
can help here?


==Dennis Jenkins