* Re: cfg_lock
From: Kumar Gala @ 2006-05-02 22:35 UTC (permalink / raw)
To: Eric Heim; +Cc: linuxppc-embedded
In-Reply-To: <20060502220242.2001.qmail@web37812.mail.mud.yahoo.com>
On May 2, 2006, at 5:02 PM, Eric Heim wrote:
> Anybody know how the cfg_lock bit is manipulated on the MPC8349EMDS
> board? I know the bit is in the internal configuration registers
> but how is this bit flipped on boot? We are trying to boot the
> board as an agent in a PC. We can only do this using the hard
> coded option. We would like to boot the board with the reset
> config word in the I2C but we can't boot the board with the 'core
> disabled' as we would like(it only works if the core enable bit is
> set, otherwise the PC hangs and won't boot). We are hoping to use
> a pre-load command in the boot sequencer, but there is little
> information on how this can be done or if it can be done. We can
> flip the bit from u-boot or using our driver when the PC has booted
> up but we need some way to flip the bit during boot to allow our PC
> to get its proper configuration cycles. Any ideas?
You have the right idea about using the I2C to handle various
register and config writes. However, the UM details how to setup
your EEPROM so that I2C boot sequencer can process it.
See section 4.4.3 in the UM.
- k
^ permalink raw reply
* U-boot1.1.4 porting problem on PPC 440GX
From: pravin @ 2006-05-02 22:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
Hi All,
I build uboot1.1.4 for ocotea_config and run on an ocotea without SPD on DIMMS (SDRAM) and It works. We manufactured another board derived from Ocotea Ref design, 440GX processor and on baord SDRAM (DIMMS) 256MB discrete parts. I use the same Uboot1.1.4 for this board. It boots upto calling the
relocate_code in cpu/ppc4xx/start.S and hangs. The same code works well on Ocotea. I run the memory tests and it passed all.
Any idea why this could hang and never finish the relocate_code function. Trying relocating Uboot to SDRAM memory to get the C environment and run from memory.
Any help would be appreciated. Any idea if i need any special code because of the discrete parts of SDRAM on our board.
Thanks,
Pravin
[-- Attachment #2: Type: text/html, Size: 919 bytes --]
^ permalink raw reply
* Re: U-boot1.1.4 porting problem on PPC 440GX
From: Eugene Surovegin @ 2006-05-02 22:55 UTC (permalink / raw)
To: pravin; +Cc: linuxppc-embedded
In-Reply-To: <20060502223259.55214.qmail@web50512.mail.yahoo.com>
On Tue, May 02, 2006 at 03:32:59PM -0700, pravin wrote:
> Hi All,
> I build uboot1.1.4 for ocotea_config and run on an ocotea without SPD on DIMMS (SDRAM) and It works. We manufactured another board derived from Ocotea Ref design, 440GX processor and on baord SDRAM (DIMMS) 256MB discrete parts. I use the same Uboot1.1.4 for this board. It boots upto calling the
>
> relocate_code in cpu/ppc4xx/start.S and hangs. The same code works well on Ocotea. I run the memory tests and it passed all.
>
> Any idea why this could hang and never finish the relocate_code function. Trying relocating Uboot to SDRAM memory to get the C environment and run from memory.
>
> Any help would be appreciated. Any idea if i need any special code because of the discrete parts of SDRAM on our board.
You can use Ocotea code (kernel and/or U-Boot) as-is for your board
only in one case - your board is _identical_ to Ocotea.
I doubt that this is the case, so you have to modify U-Boot and/or
kernel board support code to accommodate any differences between Ocotea
and your design.
Start with asking your hardware people about such differences.
--
Eugene
^ permalink raw reply
* Re: U-boot1.1.4 porting problem on PPC 440GX
From: Wolfgang Denk @ 2006-05-02 23:34 UTC (permalink / raw)
To: pravin; +Cc: linuxppc-embedded
In-Reply-To: <20060502225540.GA25045@gate.ebshome.net>
In message <20060502225540.GA25045@gate.ebshome.net> Eugene Surovegin wrote:
>
> Start with asking your hardware people about such differences.
...and then post to a mailing list (like u-boot-users) where your
questions fit. Here they are off topic.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Q: Do you know what the death rate around here is?
A: One per person.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-02 23:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200605021259.24157.arnd@arndb.de>
>> Is there any reason the driver wouldn't build and/or run on other
>> platforms? If so, fix it. If not, just make it
>>
>> depends on PCI
>
> Well, it could run on other platforms, except:
>
> - it requires a few properties in the device tree (local-mac-address,
> firmware), so it should also depend on PPC
The portions of code that require OF should have appropriate #ifdef
guards.
> - It's not actually PCI at all, but on an internal bus that has
> something close enough to a PCI config space.
Our emulation should be good enough; if not, holler (off-list).
Segher
^ permalink raw reply
* Re: Configuring PCI w/ 44x
From: Eugene Surovegin @ 2006-05-02 23:49 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-embedded
In-Reply-To: <OF7EB5CFE4.CBC11341-ON87257162.0071F2FC-85257162.0072FFA5@us.ibm.com>
On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote:
> I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3 as
> a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig is
> not enabled to reflect/change the setting for 44x. When I update
> arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x, and
> then don't configure it, the kernel won't compile:
Hmm, you cannot disable PCI for 44x in the current 2.6. It's always
enabled.
If you changed Konfig to be able to do so, why are you complaining
here? It's not enough to just change Konfig, you have to modify Ocotea
port as well. Look for example how this is handled for 85xx.
Patches are welcome.
--
Eugene
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-03 0:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <801072F8-7701-4BD7-81FB-A8C1AA534C2E@kernel.crashing.org>
Am Wednesday 03 May 2006 01:38 schrieb Segher Boessenkool:
> > - it requires a few properties in the device tree (local-mac-address,
> > =A0 firmware), so it should also depend on PPC
>
> The portions of code that require OF should have appropriate #ifdef =A0
> guards.
Why should we? Getting the mac address and the firmware into the
chip is rather essential to make it work. When there is an #ifdef
around that code, it will only produce a non-working driver that can
be compiled everywhere instead of a driver that can only be compiled
on platforms where it has a chance of working.
If someone has the need to make it work somewhere else, it's easy
enough to change to code to whatever other method is used to set up
the chip.
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Paul Mackerras @ 2006-05-03 2:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann, linux-kernel
In-Reply-To: <801072F8-7701-4BD7-81FB-A8C1AA534C2E@kernel.crashing.org>
Segher Boessenkool writes:
> > Well, it could run on other platforms, except:
> >
> > - it requires a few properties in the device tree (local-mac-address,
> > firmware), so it should also depend on PPC
>
> The portions of code that require OF should have appropriate #ifdef
> guards.
So you're suggesting that we change the Makefile so we can *add*
ifdefs? Usually we do it the other way around. :)
Paul.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-03 6:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann, linux-kernel
In-Reply-To: <17496.6519.733076.663815@cargo.ozlabs.ibm.com>
>>> Well, it could run on other platforms, except:
>>>
>>> - it requires a few properties in the device tree (local-mac-
>>> address,
>>> firmware), so it should also depend on PPC
>>
>> The portions of code that require OF should have appropriate #ifdef
>> guards.
>
> So you're suggesting that we change the Makefile so we can *add*
> ifdefs? Usually we do it the other way around. :)
Yeah, what was I thinking. So use some platform hook instead.
But Arnd of course is right; if the driver (currently) only works
on a certain platform, just mark it as such in the Makefile (erm,
Kconfig file).
Hey, we should probably do that with 90% of all drivers. But that
is a discussion for some other day :-)
Segher
^ permalink raw reply
* Re: question on why hvc_console calls hvc_poll() in hvc_handle_interrupt().
From: Michael Ellerman @ 2006-05-03 7:42 UTC (permalink / raw)
To: Ryan Arnold; +Cc: linuxppc-dev, cbe-oss-dev, Milton Miller
In-Reply-To: <1145564752.29313.185.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Thu, 2006-04-20 at 15:25 -0500, Ryan Arnold wrote:
> While on the topic of hvc_console; I think I saw a patch go through a
> while ago that added hvc_poll() to hvc_handle_interrupt(). I can't say
> I'm too pleased with that addition. I did my best to keep locking
> outside of the interrupt handler.
>
> I wonder if that change was tested on a power5 lpar system with several
> secondary VSerial Server adapters (hvc1-hvcn) being hammered with data.
> I'm pretty paranoid about deadlock, hence the reason for keeping locking
> out of the int. handler.
That was Milton's patch. No idea whether it's correct/tested.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* mpc8270 : i2c support
From: jfaslist @ 2006-05-03 12:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 1153 bytes --]
Hi,
We have designed a system using a mpc8270 cpu. The firmware we
use is u-boot and we can access all our i2c devices from u-boot.
But when we try to access i2c devices from under linux 2.6 using
the /dev/i2c-0 special file we get an ENODEV on opening that
file. I think it is because we lack an adapter driver.
If I look in the official kernel, it looks like the adapter
driver for the mpc8270 i2c system is
./drivers/i2c/busses/i2c-mpc.c. Is this correct?
Why is this driver registering as a platform driver and not as a
i2c bus driver?
In DENX ELDK there is also a i2c-mpc8260.c, but we couldn't get
that to work either.
What should I do to be able to access i2c devices using the
/dev/i2c-0 file? I feel I need to modify the i2c adapter driver
to follow the driver model, but in what ways?
Thx for any help,
-jf simon
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply
* Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Andrew Morton @ 2006-05-03 12:43 UTC (permalink / raw)
To: Jörn Engel
Cc: schickhj, linux-kernel, openib-general, linuxppc-dev, RAISCH,
HNGUYEN, MEDER
In-Reply-To: <20060427125726.GK32127@wohnheim.fh-wedel.de>
On Thu, 27 Apr 2006 14:57:26 +0200
J=F6rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> Don't expect much cheer and rejoicing over this. I suspect that akpm
> or Linus will either want the 17 patches merged into one or have a
> patchset where every single patch leaves the kernel in a working
> state, including working eHCA driver.
It doesn't matter in this case. The "don't break the build at any stage of
a series" preference exists because it's extremely irritating to hit a
won't-build in the middle of a git-bisect operation.
But anybody who is bisection searching for a bug won't want to enable a
brand-new driver in their config, so no problems.
^ permalink raw reply
* MPC5200 I2C unstable?
From: Kimmo Surakka @ 2006-05-03 13:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm using a MPC5200 based board (namely TQM5200) and the
linuxppc_2_4_devel-2005-10-25-1440 kernel from denx.de. To get the serial
ports more stable, I've applied the serial port patch by Achim Machura (can
be found in
http://marc.theaimsgroup.com/?l=linuxppc-embedded&m=112901824515097&w=2). The
patch needed small adjustments, but nothing too large -- mostly different
line numbers.
Also, to get the first I2C interface to work, I've had to change the file
drivers/i2c/i2c-tqm5200.c followingly:
-#define MPC5xxx_I2C1_ENABLE 0 /* Disable */
+#define MPC5xxx_I2C1_ENABLE 1 /* Enable */
The code compiles OK, but the I2C bus gets stuck after a short while. Has
anyone else experienced something similar? I tried to Google for information
but didn't find anything relevant. Maybe I just didn't know the right
keywords to search for?
Thanks in advance,
Kimmo Surakka
This message has been scanned by F-Secure Anti-Virus
### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ###
Unless stated above to be non-confidential, this E-mail and any
attachments are private and confidential and are for the addressee
only and may not be used, copied or disclosed save to the addressee.
If you have received this E-mail in error please notify us upon receipt
and delete it from your records. Internet communications are not secure
and Oxford Instruments is not responsible for their abuse by third
parties nor for any alteration or corruption in transmission.
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Christoph Raisch @ 2006-05-03 13:56 UTC (permalink / raw)
To: Paul Mackerras
Cc: linux-kernel, openib-general, linuxppc-dev, Hoang-Nam Nguyen,
Marcus Eder, Jörn Engel
In-Reply-To: <17489.18630.75412.66803@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote on 28.04.2006 00:42:14:
> Mind you, since a lot of the parameters are used to return individual
> bytes or half-words, which are then put into structures, it might be
> better to pass the pointers to the structures and let the wrapper put
> the values straight into the structures.
>
> Paul.
As Paul already mentioned we can't change the firmware interface.
...so we would propose the following solution:
For the two h_call wrappers with more than 8 parameters we'll change to the
following signature:
hipz_h_alloc_resource_cq(const struct ipz_adapter_handle adapter_handle,
struct ehca_cq *cq, /* used for input and output
parameters */
const struct ipz_eq_handle eq_handle);
hipz_h_alloc_resource_qp(const struct ipz_adapter_handle adapter_handle,
struct ehca_qp * qp, /* used for input and output
parameters */
struct ehca_alloc_qp_params * param); /*input
params not in ehca_qp*/
hipz_h_alloc_resource_mr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
const u64 vaddr,
const u64 length,
const u32 access_ctrl,
const struct ipz_pd pd);
u64 hipz_h_query_mr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr);
u64 hipz_h_reregister_pmr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
const u64 vaddr_in,
const u64 length,
const u32 access_ctrl,
const struct ipz_pd pd,
const u64 mr_addr_cb);
u64 hipz_h_register_smr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
struct ehca_mr *orig_mr,
const u64 vaddr_in,
const u32 access_ctrl,
const struct ipz_pd pd);
What do you think about this solution?
Gruss / Regards . . . Christoph Raisch
^ permalink raw reply
* Impossible to open the root console with 2.6.15
From: Jean-Marie Teuler @ 2006-05-03 13:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
I am trying to use ELDK 4.0 on my TQM860L board.
I have compiled the included 2.6.15 kernel with reasonable options, but
when I try to boot it, I do not get the prompt after the message
"Uncompressing Kernel Image ... OK"
Actually, I know that the system is not hanging because
1) I see there is network traffic between the board and the NFS server
2) There are messages written in /var/log/messages, and I see that the
initialization is completed (even my /etc/rc.local has been executed)
So I suspect that the problem comes from reading/writing on the console.
As my /etc/inittab has the line
...............................................
3:2345:respawn:/sbin/mingetty --noclear console
...............................................
I have put a wrapper around the binary "mingetty" and I have checked
that indeed it is called... only that I do not see anything on the
screen.
I am pretty sure that this problem is related to the kernel because if I
boot on a 2.4 kernel with the same root filesystem everything works
fine.
With the 2.4 kernel I had the following messages in /var/log/messages
.................................................................
Jan 22 12:16:34 tqm kernel: ttyS0 at 0x0280 is on SMC1 using BRG1
Jan 22 12:16:34 tqm kernel: ttyS1 at 0x0380 is on SMC2 using BRG2
.................................................................
and with the 2.6
......................................................................
Jan 26 20:25:26 tqm kernel: ttyCPM0 at MMIO 0xfff00a80 (irq = 20) is a
CPM UART
Jan 26 20:25:26 tqm kernel: ttyCPM1 at MMIO 0xfff00a90 (irq = 19) is a
CPM UART
......................................................................
I have tried to create these devices with the following characteristics:
......................................................................
crw-rw---- 1 root root 204, 46 mai 3 14:43 dev/ttyCPM0
crw-rw---- 1 root root 204, 47 mai 3 14:43 dev/ttyCPM1
......................................................................
but to no avail.
I have seen that there are many new options related to serial lines in
the new kernel, so I guess that I am doing something wrong.
Thanks in advance for any hint.
Jean-Marie Teuler
........................................................................
: Jean-Marie Teuler : :
: Laboratoire de Chimie Physique : Téléphone (33) (1) 69 15 42 05 :
: Université de Paris-sud : Télécopie (33) (1) 69 15 61 88 :
: Bâtiment 349 : Mél teuler@lcp.u-psud.fr :
: 91 405 Orsay Cedex : Web http://www.lcp.u-psud.fr :
........................................................................
^ permalink raw reply
* Re: MPC5200 I2C unstable?
From: Arno Geissel @ 2006-05-03 14:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605031608.47579.kimmo.surakka@oxinst.fi>
As far as I know there are hardware problems on the MPC5200 I2C
interface. They should be solved in the revision B
Arno
> Hi,
>
> I'm using a MPC5200 based board (namely TQM5200) and the
> linuxppc_2_4_devel-2005-10-25-1440 kernel from denx.de. To get the serial
> ports more stable, I've applied the serial port patch by Achim Machura (can
> be found in
> http://marc.theaimsgroup.com/?l=linuxppc-embedded&m=112901824515097&w=2).
> The patch needed small adjustments, but nothing too large -- mostly
> different line numbers.
>
> Also, to get the first I2C interface to work, I've had to change the file
> drivers/i2c/i2c-tqm5200.c followingly:
>
> -#define MPC5xxx_I2C1_ENABLE 0 /* Disable */
> +#define MPC5xxx_I2C1_ENABLE 1 /* Enable */
>
> The code compiles OK, but the I2C bus gets stuck after a short while. Has
> anyone else experienced something similar? I tried to Google for
> information but didn't find anything relevant. Maybe I just didn't know the
> right keywords to search for?
>
> Thanks in advance,
>
> Kimmo Surakka
>
> This message has been scanned by F-Secure Anti-Virus
>
> ### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ###
>
> Unless stated above to be non-confidential, this E-mail and any
> attachments are private and confidential and are for the addressee
> only and may not be used, copied or disclosed save to the addressee.
> If you have received this E-mail in error please notify us upon receipt
> and delete it from your records. Internet communications are not secure
> and Oxford Instruments is not responsible for their abuse by third
> parties nor for any alteration or corruption in transmission.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* kernel debugging
From: Steve Iribarne (GMail) @ 2006-05-03 14:11 UTC (permalink / raw)
To: linuxppc-embedded
Hello.
This is more a general question to see what others do out here. I am
begining to get sick of printk debugging. I work on two different PPC
boards. An 860 and 8260.
I want to get some feedback on the best kernel debugger to use. I
have been looking at three.
1. kgdb
2. kdb
3. UML
I am leaning towards kgdb, but before I jump in I thought I'd put this
out to the best group I could think of linuxppc. Because I am sure
most of you are using something! :)
Thanks.
-stv
^ permalink raw reply
* Performance improvement Montavista 3.0 MPC8260 by D-cache enable
From: Om Vadlapatla @ 2006-05-03 14:26 UTC (permalink / raw)
To: linuxppc-embedded
I want to confirm if the Montavista linux version 3.0
for the MPC8260 has the data cache working.
I work on an SDH unit that uses 2 channels and we are
about to recieve a shipment of new harware that has to
support 4 serial optical channels.
I need to confirm if the version of linux we are using
has the data chache enabled as I am about to spend a
lot of time on the data cache.
Thank you,
Best Regards,
Om Vadlapatla
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Maple freezing on PCI Target-Abort
From: jfaslist @ 2006-05-03 15:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev
In-Reply-To: <1139011975.8543.4.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 4211 bytes --]
Hi,
Back on this old posting, we have made progress thanks to IBM help, the
Maple platform no longer freezes on a (PIO) PCI target-abort. On such an
occurence we now run the machine check excpetion handler, just like you
said.
Here is what we got from IBM:
"...
Engineering has verified following behavior relating to Machine Check
and Check Stop. CPC925 documentation will be updated.
1. With APIMASK register DerrEXCP set to 1 the target abort on the
PCI bus causes P_CSTP signal to be driven low.
2. With APIMASK register DerrEXCP set to 0 and APIEMASK register
DerrEXCP set to 0 the target abort on the PCI bus causes machine
check interrupt. In this case the CHP_FAULT signal continues to be
driven high. It appears that the EI interface has a way of
signaling machine check since both pins P_CSTP and CHP_FAULT are
disabled through APIMASK and APIEMASK.
3. With APIMASK register DerrEXCP set to 0 and APIEMASK register
DerrEXCP set to 1 the target abort on the PCI bus causes machine
check interrupt. In this case the CHP_FAULT signal is driven low
until the APIEXCP is read. After APIEXCP register is read the
CHP_FAULT signal is again driven high. Since the CHP_FAULT pin is
not connected to the PPC970FX MCP_B input pin EI bus has a way of
signaling machine check through EI interface...."
Setting the CPC925 according to item 3, fixes the problem. I give this
for the record, since the fix should be in PIBS, I think.
I still don't like the fact that a user process causing the condition
causes the system to enter the "mon" debugger rather than being killed
w/ SIGBUS/SIGSEGV. I guess the correct way for a fix would be to write a
Maple specific machine_check exception?
Thanks,
-jf simon
Benjamin Herrenschmidt wrote:
>On Fri, 2006-02-03 at 16:58 +0100, jfaslist wrote:
>
>
>>Hi,
>>Yes, we are going to dig into all this CPC925 and Processor Interface
>>initialization.
>>Note that I checked that both MSR_ME and MSR_RI were set prior to
>>triggering the PCI Target-Abort.
>>
>>-MSR_ME: If not set the CPU will "checkstop" on a machine chaeck.
>>-MSR_RI: So that the exception is recoverable.
>>
>>Regarding MSR_RI, this should always be set, I think?
>>
>>
>
>Yes, MSR:RI is always set by the kernel except in the rare code path
>where taking an exception is actually unsafe (like in some of the
>exception handling code itself)
>
>Ben.
>
>
>
>
-------- Original Message --------
Subject: Re: Maple freezing on PCI Target-Abort
Date: Fri, 03 Feb 2006 12:42:37 +1100
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: jfaslist <jfaslist@yahoo.fr>
CC: linuxppc64-dev@ozlabs.org
References: <43E23B4A.4020402@yahoo.fr>
> -What exception vector is taking care of a DERR excp? From what I can
> see it seems to be the "machine check" vector. But that seems a bit
> drastic to me. After all this is just a PCI target abort.
I would expect a machine check yes.
> -I expect that the normal behavior would be for the kernel to send a
> signal termination to the user process which caused the PIO READ PCI
> cycle (from a previously mmap()'ed VMA address). Is it doable on this
> platform? Since a READ operation is coupled by nature, I think this is
> the only acceptable way.
It should SIGBUS except if the problem occurred in the kernel. I don't
know why it's not doing so, maybe you are hitting an issue/errata or
misconfiguration of the 925 ?
> I have tried to set the MSR[RI] bit before doing the PCI cycle, but it
> didn't change change anything. Also on our design we disconnect the
> CPC925 checkstop pin from the 970 machine check pin.(see page 39 of
> cpc925 user's manual). So a DERR shouldn't cause a machine check I would
> think.
>
> I realize that these questions are very H/W related but couldn't find
> the answer in IBM doc.
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply
* Re: Maple freezing on PCI Target-Abort
From: Segher Boessenkool @ 2006-05-03 15:40 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc64-dev
In-Reply-To: <4458C89B.9070505@yahoo.fr>
> I still don't like the fact that a user process causing the
> condition causes the system to enter the "mon" debugger rather than
> being killed w/ SIGBUS/SIGSEGV. I guess the correct way for a fix
> would be to write a Maple specific machine_check exception?
arch/powerpc/kernel/traps.c:machine_check_exception() does
check for user mode, and if so, throws SIGBUS. It doesn't
do this if CONFIG_PPC64 though; that's a bug.
I'm not sure if the user-mode check should be done before
or after the machine-specific handler though. Ben?
Segher
^ permalink raw reply
* Re: kernel debugging
From: David Hawkins @ 2006-05-03 16:06 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605030711q69426a59j28db8e38be73f1f0@mail.gmail.com>
> This is more a general question to see what others do out here. I am
> begining to get sick of printk debugging. I work on two different PPC
> boards. An 860 and 8260.
>
> I want to get some feedback on the best kernel debugger to use. I
> have been looking at three.
>
> 1. kgdb
> 2. kdb
> 3. UML
>
> I am leaning towards kgdb, but before I jump in I thought I'd put this
> out to the best group I could think of linuxppc. Because I am sure
> most of you are using something! :)
Hey Steve,
You've missed the most important one; a hardware debugger. I believe
most people using PPC use a BDI2000 from Abatron. They're about $3k.
I recently received one, but haven't had time to work on my PPC
stuff, so can't comment further. I'm sure everyone else on the
list will help with comments.
Note that if you use a bunch of different PPC cores, you need to
add $1k per core for the firmware uploads to the BDI2000. So if
you are working with say AMCC 440, Freescale e300/G2, e500, etc
you'll need a firmware image for each due to the debug core
differences (I guess).
The US distributor for the BDI2000 is Ultimate Solutions,
www.ultsol.com.
Cheers
Dave
^ permalink raw reply
* Re: Impossible to open the root console with 2.6.15
From: jfaslist @ 2006-05-03 17:04 UTC (permalink / raw)
To: Jean-Marie Teuler; +Cc: linuxppc-embedded
In-Reply-To: <1146663369.2448.25.camel@khnoum.lcp.u-psud.fr>
Jean-Marie Teuler wrote:
>Hi there,
>
>I am trying to use ELDK 4.0 on my TQM860L board.
>
>I have compiled the included 2.6.15 kernel with reasonable options, but
>when I try to boot it, I do not get the prompt after the message
>"Uncompressing Kernel Image ... OK"
>
>
It could be a FAQ:
http://www.denx.de/wiki/DULG/LinuxHangsAfterUncompressingKernel
But in fact, wwe had a similar case recently (no console outputs, but
linux running OK) and I am told that the problem was with the "virtual
terminal" option that needed to be disabled:
Device Drivers
-> Character devices
-> [ ] Virtual Terminal
serial drivers->
<*> CPM SCC/SMC serial port support
<*> Support for console CMP SCC/SMC serial port......
--
Best regards,
_______________________________________
jean-francois simon - themis computer
5, rue irene joliot curie
38330 eybens - france
+33 (0)870 448 638
+33 (0)4 76 14 77 85
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply
* Fw: Configuring PCI w/ 44x
From: Stephen Winiecki @ 2006-05-03 17:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
Eugene Surovegin <ebs@ebshome.net> wrote on 05/02/2006 07:49:16 PM:
> On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote:
> > I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3
as
> > a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig
is
> > not enabled to reflect/change the setting for 44x. When I update
> > arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x,
and
> > then don't configure it, the kernel won't compile:
>
> Hmm, you cannot disable PCI for 44x in the current 2.6. It's always
> enabled.
>
> If you changed Konfig to be able to do so, why are you complaining
> here? It's not enough to just change Konfig, you have to modify Ocotea
> port as well. Look for example how this is handled for 85xx.
>
> Patches are welcome.
>
> --
> Eugene
>
I was first wondering if for some reason defaulting/forcing PCI to always
be configured for 44x was intentional. I was second reporting the fact
that if a change is made to not configure PCI for 44x, the kernel will not
compile.
Steve
[-- Attachment #2: Type: text/html, Size: 1338 bytes --]
^ permalink raw reply
* Re: Fw: Configuring PCI w/ 44x
From: Eugene Surovegin @ 2006-05-03 17:18 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-embedded
In-Reply-To: <OF417BCEEB.CBCC9EBC-ON87257163.005DB572-85257163.005E34EB@us.ibm.com>
On Wed, May 03, 2006 at 01:11:26PM -0400, Stephen Winiecki wrote:
>
> Eugene Surovegin <ebs@ebshome.net> wrote on 05/02/2006 07:49:16 PM:
>
> > On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote:
> > > I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3
> as
> > > a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig
> is
> > > not enabled to reflect/change the setting for 44x. When I update
> > > arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x,
> and
> > > then don't configure it, the kernel won't compile:
> >
> > Hmm, you cannot disable PCI for 44x in the current 2.6. It's always
> > enabled.
> >
> > If you changed Konfig to be able to do so, why are you complaining
> > here? It's not enough to just change Konfig, you have to modify Ocotea
> > port as well. Look for example how this is handled for 85xx.
> >
> > Patches are welcome.
> >
> > --
> > Eugene
> >
>
> I was first wondering if for some reason defaulting/forcing PCI to always
> be configured for 44x was intentional.
Yes. I think it's quite obvious from the way it's configured in
Konfig.
> I was second reporting the fact
> that if a change is made to not configure PCI for 44x, the kernel will not
> compile.
Well, I don't follow you here. You made the wrong change and report
here that it broke the build. How is this interesting?
Your report looked as you discovered a bug, when in fact you broke the
build yourself.
And again, if disabling PCI is important to you you are welcome to
submit patches instead of sending misleading e-mails to this list.
--
Eugene
^ permalink raw reply
* RE: Performance improvement Montavista 3.0 MPC8260 by D-cache enable
From: Om Vadlapatla @ 2006-05-03 18:34 UTC (permalink / raw)
To: srideep.devireddy, linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A07E24DF9@CHN-SNR-MBX01.wipro.com>
How do you suggest I go about enabling the data cache
with out running into the machine check exception
(0200 exception).
I need the data cache as there is lot of data access
in the applications we run on our SDH unit.
OS Montavista 3.0
Processor MPC8260
Register required to madify: HID0 (bit 17 to be set)
=> controlword is: HID0 OR 000004000 => sets the 17th
bit
but this gives me the 0200 exception
are there any kernel routines I can run to get this to
work?
Thank you,
Sincerely,
Om Vadlapatla
--- srideep.devireddy@wipro.com wrote:
> Data chache is not enabled you have to enable it
> ......
>
> srideep
>
> -----Original Message-----
> From:
>
linuxppc-embedded-bounces+srideep.devireddy=wipro.com@ozlabs.org
>
[mailto:linuxppc-embedded-bounces+srideep.devireddy=wipro.com@ozlabs.org
> ] On Behalf Of Om Vadlapatla
> Sent: Wednesday, May 03, 2006 7:57 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Performance improvement Montavista 3.0
> MPC8260 by D-cache
> enable
>
> I want to confirm if the Montavista linux version
> 3.0
> for the MPC8260 has the data cache working.
>
> I work on an SDH unit that uses 2 channels and we
> are
> about to recieve a shipment of new harware that has
> to
> support 4 serial optical channels.
>
> I need to confirm if the version of linux we are
> using
> has the data chache enabled as I am about to spend a
> lot of time on the data cache.
>
> Thank you,
> Best Regards,
>
> Om Vadlapatla
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox