RE: problem with standard libc on 8xx

RE: problem with standard libc on 8xx

[Demke, Torsten]

Hello Wolfgang,

so what is your proposal, to solve the problem?
I would like to use Debian binaries, but I cannot
use the floating point emulation of the kernel!?

Regards,
Torsten


> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Freitag, 27. Februar 2004 10:43
> To: Demke, Torsten
> Cc: Linuxppc-Embedded (E-mail)
> Subject: Re: problem with standard libc on 8xx
>
>
> In message
> <9CFB9DA5261CD611A29B00508B78904807F880ED@ex-deu-munich02.forc
> e.de> you wrote:
> >
> > I created my own root-fs for a MPC8xx platform
> > using standard Debian packages (including libc).
> > When I start the system, the init scripts hangs
> ...
> > I guess that the Debian libc uses floating point - which
>
> Thi sis definitely one cause of the problem.  Another  one  might  be
> optimization  for  a  incorrect  cache  line  size  (32 instead of 16
> bytes).
>
> > is not available on MPC8xx - but I thougt the kernel would
> > emulate this calls (CONFIG_MATH_EMULATION=y).
>
> This has never been working reliably for any real-life code. And it's
> awfully slow.
>
> Also note that you CANNOT mix standard binaries (from Debian) and 8xx
> specific libraries (from ELDK) -  this  will  crash  as  soon  as  an
> application attempts to use floating point.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> Above all else -- sky.
>

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

Re: problem with standard libc on 8xx

[Wolfgang Denk]

In message <9CFB9DA5261CD611A29B00508B78904807F88115@ex-deu-munich02.force.de> you wrote:
>
> so what is your proposal, to solve the problem?

Use libraries and binaries that were built for a 8xx system.

> I would like to use Debian binaries, but I cannot
> use the floating point emulation of the kernel!?

I'm afraid you cannot.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Old programmers never die, they just branch to a new address.

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

MMU Problem bringing up kernel with PPC 603 chip

[Bob Beck]

All,

I'm bringing up my 1st kernel on a proprietary board
using a PPC 603E chip.


The kernel is configured using the 6xx/7xx ppc selection.

The kernel starts executing at __start in head.S and
branches to early_init(). I have stubbed out the call
to prom_init() since this is an embedded system and
not a power mac (as the comments at the top of the
prom.c file indicate).

The code returns to head.S and branches to mmu_off.
Here is the code for mmu_off.

mmu_off:
	addi	r4, r3, __after_mmu_off - _start
	mfmsr	r3
	andi.	r0,r3,MSR_DR|MSR_IR		/* MMU enabled? */
	beqlr
	andc	r3,r3,r0
	mtspr	SRR0,r4
	mtspr	SRR1,r3
	sync
	RFI

This executes all the way to the "RFI" instruction,
but never comes back to the place in the code that
called mmu_off.

Why is the "return from interrupt" going out into
space ? Any suggestions ?


Best Regards,

Bob Beck
beck@assurtech.com


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

RE: MMU Problem bringing up kernel with PPC 603 chip

[VanBaren, Gerald (AGRE)]

You are turning off the MMU when you execute the RFI.  This is a very delicate operation: any screw up here causes the machine to crash mysteriously.  Oh, wait, you know that already ;-).

Questions: Why is your MMU on when you call this routine?  Who turned it on?  Why?  What is the MMU mapping to/from?

Several suspect areas:
* You have cache enabled and are using the MMU to mark areas as cache-inhibited (necessary for all I/O type stuff).  When you disable the MMU, _everything_ becames cached by fiat, causing all I/O to become cached.  At this point, the CPU state is indistingishable from crashed because it is being held hostage by the cache (nothing comes in, nothing goes out).  Solution: disable the cache before disabling the MMU.

* Your MMU is not mapping memory 1:1 so turning it off makes your memory disappear out from under your CPU.  Crash.  Solution: you need to return (RFI) to an area of memory that will exist when the MMU is disabled.

gvb


> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf
> Of Bob Beck
> Sent: Thursday, February 26, 2004 4:23 PM
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: MMU Problem bringing up kernel with PPC 603 chip
>
>
>
> All,
>
> I'm bringing up my 1st kernel on a proprietary board
> using a PPC 603E chip.
>
>
> The kernel is configured using the 6xx/7xx ppc selection.
>
> The kernel starts executing at __start in head.S and
> branches to early_init(). I have stubbed out the call
> to prom_init() since this is an embedded system and
> not a power mac (as the comments at the top of the
> prom.c file indicate).
>
> The code returns to head.S and branches to mmu_off.
> Here is the code for mmu_off.
>
> mmu_off:
> 	addi	r4, r3, __after_mmu_off - _start
> 	mfmsr	r3
> 	andi.	r0,r3,MSR_DR|MSR_IR		/* MMU enabled? */
> 	beqlr
> 	andc	r3,r3,r0
> 	mtspr	SRR0,r4
> 	mtspr	SRR1,r3
> 	sync
> 	RFI
>
> This executes all the way to the "RFI" instruction,
> but never comes back to the place in the code that
> called mmu_off.
>
> Why is the "return from interrupt" going out into
> space ? Any suggestions ?
>
>
> Best Regards,
>
> Bob Beck
> beck@assurtech.com
>
>


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