BootX

BootX

[kevin diggs]

Hi,

Anyone familiar with BootX? Could my problems with the 8600 be related
to some interaction with BootX?

kevin

Re: BootX

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> Hi,
> 
> Anyone familiar with BootX? Could my problems with the 8600 be related
> to some interaction with BootX?

It's possible. Have you tried using OF booting instead ? The 8600 should
be cable to boot off SCSI or netboot COFF images.

Cheers,
Ben.

Re: BootX

[kevin diggs]

Hi,

This would require quik, right? I went to penguinppc.org and tried to
get the latest BootX and quik but the links are dead. Do you know
where the latest versions are?

kevin

On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
>> Hi,
>>
>> Anyone familiar with BootX? Could my problems with the 8600 be related
>> to some interaction with BootX?
>
> It's possible. Have you tried using OF booting instead ? The 8600 should
> be cable to boot off SCSI or netboot COFF images.
>
> Cheers,
> Ben.
>
>

Re: BootX

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> Hi,
> 
> This would require quik, right? I went to penguinppc.org and tried to
> get the latest BootX and quik but the links are dead. Do you know
> where the latest versions are?

That link still works:
 
> kevin
> 
> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> to some interaction with BootX?
> >
> > It's possible. Have you tried using OF booting instead ? The 8600 should
> > be cable to boot off SCSI or netboot COFF images.
> >
> > Cheers,
> > Ben.
> >
> >

Re: BootX

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> Hi,
> 
> This would require quik, right? I went to penguinppc.org and tried to
> get the latest BootX and quik but the links are dead. Do you know
> where the latest versions are?

That link still works:

Oops... typing FAIL :-)

I meant:

http://penguinppc.org/bootloaders/quik/

However, it's possible that distros like debian have done more changes to it.

Another option is to netboot a zImage directly, which works if it's not
too big.

Cheers,
Ben.

> kevin
> 
> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> to some interaction with BootX?
> >
> > It's possible. Have you tried using OF booting instead ? The 8600 should
> > be cable to boot off SCSI or netboot COFF images.
> >
> > Cheers,
> > Ben.
> >
> >

Re: BootX

[kevin diggs]

Hi,

The link:

http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik

to download the latest source does not seem to have anything useful???

kevin

On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
>> Hi,
>>
>> This would require quik, right? I went to penguinppc.org and tried to
>> get the latest BootX and quik but the links are dead. Do you know
>> where the latest versions are?
>
> That link still works:
>
> Oops... typing FAIL :-)
>
> I meant:
>
> http://penguinppc.org/bootloaders/quik/
>
> However, it's possible that distros like debian have done more changes to it.
>
> Another option is to netboot a zImage directly, which works if it's not
> too big.
>
> Cheers,
> Ben.
>
>> kevin
>>
>> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
>> >> Hi,
>> >>
>> >> Anyone familiar with BootX? Could my problems with the 8600 be related
>> >> to some interaction with BootX?
>> >
>> > It's possible. Have you tried using OF booting instead ? The 8600 should
>> > be cable to boot off SCSI or netboot COFF images.
>> >
>> > Cheers,
>> > Ben.
>> >
>> >
>
>
>
>

Re: BootX

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 20:03 -0600, kevin diggs wrote:
> Hi,
> 
> The link:
> 
> http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik
> 
> to download the latest source does not seem to have anything useful???

Ah right. 2.0e is still there tho. Try to have a look at what's in
distros like debian or genpoo..

Cheers,
Ben.

> kevin
> 
> On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote:
> >> Hi,
> >>
> >> This would require quik, right? I went to penguinppc.org and tried to
> >> get the latest BootX and quik but the links are dead. Do you know
> >> where the latest versions are?
> >
> > That link still works:
> >
> > Oops... typing FAIL :-)
> >
> > I meant:
> >
> > http://penguinppc.org/bootloaders/quik/
> >
> > However, it's possible that distros like debian have done more changes to it.
> >
> > Another option is to netboot a zImage directly, which works if it's not
> > too big.
> >
> > Cheers,
> > Ben.
> >
> >> kevin
> >>
> >> On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt
> >> <benh@kernel.crashing.org> wrote:
> >> > On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote:
> >> >> Hi,
> >> >>
> >> >> Anyone familiar with BootX? Could my problems with the 8600 be related
> >> >> to some interaction with BootX?
> >> >
> >> > It's possible. Have you tried using OF booting instead ? The 8600 should
> >> > be cable to boot off SCSI or netboot COFF images.
> >> >
> >> > Cheers,
> >> > Ben.
> >> >
> >> >
> >
> >
> >
> >

Re: BootX

[kevin diggs]

Hi,

If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
G4 that runs is a dual cpu beast and thus also runs SMP.

I at least know this (ok, I THINK I know):

For non-SMP:  The spinlock 'acct_lock' in kernel/acct.c that IS
present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so
much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28
spinlock safari.

Don't some funky, optimizery things happen to spinlocks for the NON-smp case?

I'll see what the 4.2.x gcc does.

Thanks!

kevin

P.S.:  There is one other difference for the SMP 4.3.5 compiled
2.6.28:  my 750gx cpufreq driver gets disabled. It is fairly isolated
code though. Should not be able to nuke the spinlock in kernel/acct.c

On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> Anyone familiar with BootX? Could my problems with the 8600 be related
> to some interaction with BootX?
>
> kevin
>

Re: BootX

[kevin diggs]

Hi,

I've never done any real kernel debugging. Can anyone give any
pointers on how to do early boot debugging on an old world (buggy OF)
powermac? Can I do anything using a serial console?

A little reading last night suggested that spinlocks are supposed to
disappear for single processor machines. I do not understand why they
are present in 3.4.6 (at least the symbol anyway)? The 'acct_lock'
spin lock was also missing with gcc 4.2.4.

kevin

On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
> G4 that runs is a dual cpu beast and thus also runs SMP.
>
> I at least know this (ok, I THINK I know):
>
> For non-SMP:  The spinlock 'acct_lock' in kernel/acct.c that IS
> present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so
> much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28
> spinlock safari.
>
> Don't some funky, optimizery things happen to spinlocks for the NON-smp case?
>
> I'll see what the 4.2.x gcc does.
>
> Thanks!
>
> kevin
>
> P.S.:  There is one other difference for the SMP 4.3.5 compiled
> 2.6.28:  my 750gx cpufreq driver gets disabled. It is fairly isolated
> code though. Should not be able to nuke the spinlock in kernel/acct.c
>
> On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>> Hi,
>>
>> Anyone familiar with BootX? Could my problems with the 8600 be related
>> to some interaction with BootX?
>>
>> kevin
>>
>

Re: BootX

[kevin diggs]

Hi,

4.2.4 does NOT work.

4.1.2 DOES work.

Is there some magic PowerPC specific gcc patch somewhere? Should I
reorient the computer relative to the planet's magnetic field when I
compile with newer gcc? A magic handshake? what?

Is anyone using a compiler newer than 4.1.2?

Sorry, but I do not know where to go from here?

kevin

On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
> G4 that runs is a dual cpu beast and thus also runs SMP.
>
> I at least know this (ok, I THINK I know):
>
> For non-SMP:  The spinlock 'acct_lock' in kernel/acct.c that IS
> present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so
> much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28
> spinlock safari.
>
> Don't some funky, optimizery things happen to spinlocks for the NON-smp case?
>
> I'll see what the 4.2.x gcc does.
>
> Thanks!
>
> kevin
>
> P.S.:  There is one other difference for the SMP 4.3.5 compiled
> 2.6.28:  my 750gx cpufreq driver gets disabled. It is fairly isolated
> code though. Should not be able to nuke the spinlock in kernel/acct.c
>
> On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>> Hi,
>>
>> Anyone familiar with BootX? Could my problems with the 8600 be related
>> to some interaction with BootX?
>>
>> kevin
>>
>

Re: BootX

[kevin diggs]

Hi,

FYI:

I have narrowed this down to drivers/scsi/mesh.c (the root disk
controller for the PowerMac 8600). I have compiled everything else for
2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
beast boots. I am using it to post this follow up.

kevin

> On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs <diggskevin38@gmail.com> wrote:
>> Hi,
>>
>> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
>> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
>> G4 that runs is a dual cpu beast and thus also runs SMP.
>>

Re: BootX

[Benjamin Herrenschmidt]

On Wed, 2011-02-02 at 13:36 -0600, kevin diggs wrote:
> Hi,
> 
> FYI:
> 
> I have narrowed this down to drivers/scsi/mesh.c (the root disk
> controller for the PowerMac 8600). I have compiled everything else for
> 2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
> beast boots. I am using it to post this follow up.

That's interesting... That driver is really nasty, we probably have a
bug in it that's exposed by optimizations done by more recent compilers
but it's not going to be trivial to figure out I'm afraid. I at least
have very dim memories of mesh and how it operates...

One thing to be careful of with Mesh is that the DMA engine, while
supposedly cache coherent, has shown in the past to have issues when
DMA'ing to unaligned memory locations. This shouldn't be a problem with
normal block transfers but we may have to be careful with things like
inquiry, mode pages, sense requests etc...

Ben.

> kevin
> 
> > On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> >> Hi,
> >>
> >> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
> >> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
> >> G4 that runs is a dual cpu beast and thus also runs SMP.
> >>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: BootX

[kevin diggs]

Ben,

I know you are VERY busy. I appreciate your taking the time to reply.

Since I'm am still using this thing I'll take a stab at trying to
track it down. I just posted the FYI to see if I could trigger some
thoughts (like your post).

With a 4.3.5 compiled mesh, it fails a lot of early stuff like getting
cache info? I don't remember the full list because it fails to find
the root fs and does the reboot in 180 seconds thing (I still have in
a back corner of my brain the serial console xmon boot stuff and will
probably eventually try that).

I am hopeful that since it (at least so far) always fails that it
might not be THAT bad to track down. That coupled with some knowledge
of what the compilers are doing differently can hopefully help track
it down.

Thanks!

kevin

On Wed, Feb 2, 2011 at 3:40 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> That's interesting... That driver is really nasty, we probably have a
> bug in it that's exposed by optimizations done by more recent compilers
> but it's not going to be trivial to figure out I'm afraid. I at least
> have very dim memories of mesh and how it operates...
>
> One thing to be careful of with Mesh is that the DMA engine, while
> supposedly cache coherent, has shown in the past to have issues when
> DMA'ing to unaligned memory locations. This shouldn't be a problem with
> normal block transfers but we may have to be careful with things like
> inquiry, mode pages, sense requests etc...
>
> Ben.
>

Re: BootX

[kevin diggs]

Hi,

And one more thing:  Why does an SMP kernel (mesh compiled in an SMP
enabled kernel) work?

What all does SMP do? If it matters, I'm voluntary preempt.

Is the DMA hardware in this thing used in any other system (I guess I
mean both other computers and other sub-systems in this computer -
does the 53c94 use it? The audio uses it, right?)?

kevin

Re: BootX

[Benjamin Herrenschmidt]

On Wed, 2011-02-02 at 16:09 -0600, kevin diggs wrote:
> Hi,
> 
> And one more thing:  Why does an SMP kernel (mesh compiled in an SMP
> enabled kernel) work?

Could be an alignment or timing problem, depending on random things the
alignment of some DMA data structures or timing of access might end up
being subtely different.
 
> What all does SMP do? If it matters, I'm voluntary preempt.
> 
> Is the DMA hardware in this thing used in any other system (I guess I
> mean both other computers and other sub-systems in this computer -
> does the 53c94 use it? The audio uses it, right?)?

The DBDMA engine is used in various Apple chips but with more or less HW
bugs in it :-)

To get some more info about the MESH, I suggest you google for a
document called "MacTech.pdf" (Macintosh Technology in the
Common Hardware Reference Platform).

This describes the "MacIO" chip that was designed by Apple for CHRP
machines, which is a successor of the Bandit chip which I think contains
the MESH on your machine. The basic IO cells like MESH are the same (tho
it's possible that the one you have contains more bugs).

Cheers,
Ben.

Re: BootX

[kevin diggs]

Hi,

FYI:

This driver has some pretty good diagnostics/debug capabilities built
in. Once that is enabled it shows that the inquiry works and the sync
negotiation works. The next command (I think) is test unit ready,
which does not work. It is retried multiple times. The result is 20000
which I think is DID_BUS_BUSY. Probably in mesh_start_cmd(), possibly
something off in the loop at line 462?

kevin

P.S.:  I posted some documentation for dump_stack()/show_stack() but
have not heard anything? Is that not something we are interested in
doing?

Re: BootX

[Benjamin Herrenschmidt]

On Fri, 2011-02-04 at 11:21 -0600, kevin diggs wrote:
> 
> P.S.:  I posted some documentation for dump_stack()/show_stack() but
> have not heard anything? Is that not something we are interested in
> doing? 

Or I haven't had a chance to review it yet ... I'm very very busy at the
moment so things are lagging a bit.

Ben.

Re: BootX

[kevin diggs]

Hi,

I have looked at the -S output for mesh.c from both 4.1.2 and 4.3.5.
The generated code is quite different but I can not see any difference
that is causing the problem?

If I read and print the bus status register 0, it does appear to have
the busy bit set?

I'm in way over my head here. It appears to complete a pair of
inquiries (one with a small data buffer and a second with a larger
one) to each target. It then tries a test unit ready but discovers the
bus busy?

ANY suggestions welcome and appreciated!

Thanks!