any one use 750fx/MV64360

any one use 750fx/MV64360

[Xiaoshan Zuo]

Hello,

We are planning design a custom board. The preferred cpu is IBM 750FX,
the bridge is going to be Marvell 64360. Depending on the software
support, we may alter our plan to use either 750FX/64260 or Motorola
7447/64360/64260. It seems that 64360 is not supported in stock kernel,
there is galieo tree for that, but I am not sure the code is really
stable. Anyone has experience using 750fx/64360? Which version of
gcc/kernel/u-boot should I use? If that is not a good option, then how
about 750FX/64260 or Motorola 7447/64360/64260? Any suggestions/comments
will be appreciated.

Thanks,

Xiaoshan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: any one use 750fx/MV64360

[Huailin Chen]

My 2 cents:

I happened to use all your options these years:--(.

750fx + 64260
it should be good enough if you don't have
MP(Multi-CPU) demand for running smp-os on top of it.
The reason is obivous: 750fx is G3. The MEI protocol
may not be prefered if your system happens to be a
high-end applicances.

750fx + 64360

if you do want to stay 750 and need SMP, you may have
to use 64360. Check out Marvell FAE people to
understand their Arbiter part, which have some fixes
for SMP support. If you have legacy issue, note that
some tiny porting work needed for 64360 part.

7447 + 64260
No one would go for this option

7447 + 64360

Well, G4+ MES(R)I is born to support SMP system. So,
if you concern this part, do go for it. One thing you
need talk to your hardware board group is: Powerp
Consumption. If you guys are able to live with it, go
for it:-).

Also, if you have legacy codes under IBM 750-based
system, please pay high alert on driver part. For
example, Out of Order issue when under Non-Cachable
and Guard......One missing will make your driver all
srew up. For more detail, you are welcome to talk to
me.

Good luck,
Huailin Chen
www.xtrj.org




--- Xiaoshan Zuo <xzuo@vinesystech.com> wrote:
>
> Hello,
>
> We are planning design a custom board. The preferred
> cpu is IBM 750FX,
> the bridge is going to be Marvell 64360. Depending
> on the software
> support, we may alter our plan to use either
> 750FX/64260 or Motorola
> 7447/64360/64260. It seems that 64360 is not
> supported in stock kernel,
> there is galieo tree for that, but I am not sure the
> code is really
> stable. Anyone has experience using 750fx/64360?
> Which version of
> gcc/kernel/u-boot should I use? If that is not a
> good option, then how
> about 750FX/64260 or Motorola 7447/64360/64260? Any
> suggestions/comments
> will be appreciated.
>
> Thanks,
>
> Xiaoshan
>
>


Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: any one use 750fx/MV64360

[Xiaoshan Zuo]

Thanks for the comments. Those are certainly good points. What
OS did you use? Any suggestions on the Linux kernel to use?
BTW, your website is just interesting.

Xiaoshan

**** Huailin Chen wrote ****
> My 2 cents:
>
> I happened to use all your options these years:--(.
>
> 750fx + 64260
> it should be good enough if you don't have
> MP(Multi-CPU) demand for running smp-os on top of it.
> The reason is obivous: 750fx is G3. The MEI protocol
> may not be prefered if your system happens to be a
> high-end applicances.
>
> 750fx + 64360
>
> if you do want to stay 750 and need SMP, you may have
> to use 64360. Check out Marvell FAE people to
> understand their Arbiter part, which have some fixes
> for SMP support. If you have legacy issue, note that
> some tiny porting work needed for 64360 part.
>
> 7447 + 64260
> No one would go for this option
>
> 7447 + 64360
>
> Well, G4+ MES(R)I is born to support SMP system. So,
> if you concern this part, do go for it. One thing you
> need talk to your hardware board group is: Powerp
> Consumption. If you guys are able to live with it, go
> for it:-).
>
> Also, if you have legacy codes under IBM 750-based
> system, please pay high alert on driver part. For
> example, Out of Order issue when under Non-Cachable
> and Guard......One missing will make your driver all
> srew up. For more detail, you are welcome to talk to
> me.
>
> Good luck,
> Huailin Chen
> www.xtrj.org
>
>
>
>
> --- Xiaoshan Zuo <xzuo@vinesystech.com> wrote:
> >
> > Hello,
> >
> > We are planning design a custom board. The preferred
> > cpu is IBM 750FX,
> > the bridge is going to be Marvell 64360. Depending
> > on the software
> > support, we may alter our plan to use either
> > 750FX/64260 or Motorola
> > 7447/64360/64260. It seems that 64360 is not
> > supported in stock kernel,
> > there is galieo tree for that, but I am not sure the
> > code is really
> > stable. Anyone has experience using 750fx/64360?
> > Which version of
> > gcc/kernel/u-boot should I use? If that is not a
> > good option, then how
> > about 750FX/64260 or Motorola 7447/64360/64260? Any
> > suggestions/comments
> > will be appreciated.
> >
> > Thanks,
> >
> > Xiaoshan
> >
> >
>
>
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Huailin Chen]

Hi, team,

I tried to collect some documents related to linux and
ppc. And did some document(I'm not yet confident
enough to say: kernel analysis) about linux ppc
machine dependent part.

It's far away being good. But wish helpful and
meantime get some feedback so that I could make a
better job.

The Link is: www.xtrj.org/ppc

The ToC is:
-------------
Chapter 1 Embedded PowerPC Family
Chapter 2: Programming Model
Chapter 3: PowerPC EABI
Chapter 4: PowerPC Interrupt/Exception
Chapter 5: PowerPC 4xx Reset and Initialization
Chapter 6: Synchronization Requirements
Chapter 7: Linux Kernel Bootup and Initialization
Chapter 8: Kernel Initialization
Chapter 9: Kernel Setup---start_kernel
Chapter 10: Kernel Exception Handler
Chapter 11 Kernel Memory Management
Chapter 12: Kernel Process Management
Chapter 13 Interrupt Handling routines
Chapter 14 System Call handling
Chapter 15: PowerPC EABI Cross Compiler

Regards,

Huailin, Chen
www.xtrj.org


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Jon Masters]

Huailin Chen wrote:

| The Link is: www.xtrj.org/ppc

Hi there,

I think you and I are both looking at the same thing and have similar
goals so I will go through what you have put up and get in touch.

Cheers,

Jon.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Kenneth Johansson]

On Thu, 2004-01-22 at 19:58, Huailin Chen wrote:
> Chapter 3: PowerPC EABI
> Chapter 15: PowerPC EABI Cross Compiler

Well we actually use system V ABI for linux binaries and making a cross
compiler with TARGET=powerpc-linux can also use EABI with the -meabi
option.

Perhaps pointing to dan kegel's crosstool would be better than invent
your own way.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[jlhagen]

I was wondering the same thing. Maybe -> http://xtrj.org/ppc/index.htm

JH

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC KGDB changes and some help?

[Amit S. Kale]

Hi Tom,

Yes. Software breakpoints have been tested in the TimeSys ppc kernel source.
They work quite well!! I'll be releasing that code soon.

Here are a couple of questions from a quick look at this code. I may have more
when I do a merge this code with what I have.

> -	bl	schedule
> +	bl	user_schedule

I still have #ifdef CONFIG_KGDB_THREAD here. Threads listing is a necessary
feature, agreed. Do you have any ideas on reducing the overhead of the code
added by having to push all registers when doing a switch_to?

if (kgdb enabled) do a full push of registers else go to usual switch_to

Does this sound good?


> +        */
> +#if 0
> +       extern atomic_t kgdb_setting_breakpoint;
> +       if (atomic_read(&kgdb_setting_breakpoint))
> +               regs->nip += 4;
> +#else
> +       if (linux_regs->nip == 0x7d821008 )
> +               /* Skip over breakpoint trap insn */
> +               linux_regs->nip += 4;
> +#endif

Why is kgdb_setting_breakpoint a bad idea?
My guess - problems on an smp board.
Hardcoded nip is worse.
Any ideas for a better code?


In following code, gdb packets and their responses appear correct. kgdb is
supposed handle software breakpoints.

The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb
at kgdb.sourceforge.net places it correctly at module_event.

Where is the other breakpoint placed? While you would have certainly done
that, please confirm that kgdb actually inserts a breakpoint where you have
asked it to: a simple printk at the address where the breakpoint is placed
should be sufficient. printing from gdb will not work as gdb removes all
breakpoints before giving control to a user.

> Now, when I say that things don't quite work, here's a gdb log:
> Remote debugging using /dev/ttyS0
> Sending packet: $qPassSignals:0e;10;14;17;1a;1b;1c;21;24;25;4c;#df...Ack
> Packet received:
> Packet qPassSignals (pass-signals) is NOT supported
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC0000000000000001
> Sending packet: $qOffsets#4b...Ack
> Packet received:
> Sending packet: $?#3f...Ack
> Packet received: S05
> Sending packet: $Hg1#e0...Ack
> Packet received: OK
> Sending packet: $g#67...Ack
> Packet received:
> 00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01
>d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000004000000035303d30000
>0000000000000c0003dec0000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0 Sending packet: $mc002c9e8,c#2a...Ack
> Packet received: 4bffff513c60c0153863b1d0
> 0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
> 1082			wmb();
>
> << break show_cpuinfo >>
>
>
> Sending packet: $qSymbol::#5b...Ack
> Packet received:
> Packet qSymbol (symbol-lookup) is NOT supported
> Sending packet: $mc000be54,4#f0...Ack
> Packet received: 9421ffd0
> Sending packet: $mc000be58,4#f4...Ack
> Packet received: 7c0802a6
> Sending packet: $mc000be5c,4#1f...Ack
> Packet received: 39600000
> Sending packet: $mc000be60,4#ed...Ack
> Packet received: bf410018
> Sending packet: $mc000be64,4#f1...Ack
> Packet received: 90010034
> Sending packet: $mc000be68,4#f5...Ack
> Packet received: 37e4ffff
> Breakpoint 1 at 0xc000be68: file arch/ppc/kernel/setup.c, line 144.
>
> << continue >>
>
> Continuing.
> Sending packet: $Z0,c0000000,4#c9...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $Z0,c000be68,4#3e...Ack
> Packet received: OK
> Sending packet: $Hs1#ec...Ack
> Packet received:
> Sending packet: $Hc0#db...Ack
> Packet received: OK
> Sending packet: $c#63...Ack
> Packet received: S05p0000000000000001
> [New Thread 1]
> Sending packet: $g#67...Ack
> Packet received:
> 00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01
>d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000004000000035303d30000
>0000000000000c0003dec0000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> Sending packet: $mc002c9e8,c#2a...Ack
> Packet received: 4bffff513c60c0153863b1d0
> Sending packet: $z0,c0000000,4#e9...Ack
> Packet received: OK
> Sending packet: $z0,c000be68,4#5e...Ack
> Packet received: OK
> 0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
> 1082			wmb();
>
> << continue >>
>
> Continuing.
> Sending packet: $Z0,c0000000,4#c9...Ack
> Packet received: OK
> Sending packet: $Z0,c000be68,4#3e...Ack
> Packet received: OK
> Sending packet: $c#63...Ack
> Packet received: S05p0000000000000001
> Sending packet: $g#67...Ack
> Packet received:
> 00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01
>d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000004000000035303d30000
>0000000000000c0003dec0000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000
>0000000000000000000000000000000000000000000000000000000000000000000000000000
>0
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> Sending packet: $mc002c9e8,c#2a...Ack
> Packet received: 4bffff513c60c0153863b1d0
> Sending packet: $z0,c0000000,4#e9...Ack
> Packet received: OK
> Sending packet: $z0,c000be68,4#5e...Ack
> Packet received: OK
> 0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
> 1082			wmb();
>
> << quit >>
>
> The program is running.  Exit anyway? (y or n) Sending packet: $k#6b...Ack
>
>
> Which leads me to wonder, has software breakpoints been tested at all?
> PPC allows for HW breakpoints, but in general there's only 1 or 2.  And,
> FWIW, I have a much uglier version of things which overrides the
> linux_debug_hook with the working handle_exception function in
> ppc-stub.c, and found the same problem.  Also, what I'm going to try and
> do next is to add support for using the HW breakpoints and see if that
> fixes things, or at least gets me further along.
>
> Any pointers or ideas?  Thanks.

--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Huailin Chen]

Hi, team,

I tried to collect some documents related to linux and
ppc. And did some document(I'm not yet confident
enough to say: kernel analysis) about linux ppc
machine dependent part.

It's far away being good. But wish helpful and
meantime get some feedback so that I could make a
better job.

The ToC is:
-------------
Chapter 1 Embedded PowerPC Family
Chapter 2: Programming Model
Chapter 3: PowerPC EABI
Chapter 4: PowerPC Interrupt/Exception
Chapter 5: PowerPC 4xx Reset and Initialization
Chapter 6: Synchronization Requirements
Chapter 7: Linux Kernel Bootup and Initialization
Chapter 8: Kernel Initialization
Chapter 9: Kernel Setup---start_kernel
Chapter 10: Kernel Exception Handler
Chapter 11 Kernel Memory Management
Chapter 12: Kernel Process Management
Chapter 13 Interrupt Handling routines
Chapter 14 System Call handling
Chapter 15: PowerPC EABI Cross Compiler

Regards,

Huailin, Chen
www.xtrj.org

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Hollis Blanchard]

On Jan 21, 2004, at 7:13 PM, Huailin Chen wrote:
>
> I tried to collect some documents related to linux and
> ppc. And did some document(I'm not yet confident
> enough to say: kernel analysis) about linux ppc
> machine dependent part.
>
> It's far away being good. But wish helpful and
> meantime get some feedback so that I could make a
> better job.
>
> The ToC is:
> -------------
> Chapter 1 Embedded PowerPC Family
> Chapter 2: Programming Model
> Chapter 3: PowerPC EABI
> Chapter 4: PowerPC Interrupt/Exception
> Chapter 5: PowerPC 4xx Reset and Initialization
> Chapter 6: Synchronization Requirements
> Chapter 7: Linux Kernel Bootup and Initialization
> Chapter 8: Kernel Initialization
> Chapter 9: Kernel Setup---start_kernel
> Chapter 10: Kernel Exception Handler
> Chapter 11 Kernel Memory Management
> Chapter 12: Kernel Process Management
> Chapter 13 Interrupt Handling routines
> Chapter 14 System Call handling
> Chapter 15: PowerPC EABI Cross Compiler

Are you saying you intend to write a book, and do we have comments on
the proposed ToC? Or that you have begun writing a book, and the
content is online somewhere and you'd like comments? Or that it's
already written? If there's anything more than a ToC to look at, please
provide a URL. :)

--
Hollis Blanchard
IBM Linux Technology Center


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/