* MCC 8260 problem
From: Abas Javadtalab @ 2006-04-18 15:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gianfranco.morandi
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi
I have downloaded mcc source code from Source forge site. However, this source unable to execute because the Rules.make file is not found. in addition it seems that this package is incomplete source It would be glad for me if you help me about it.
Best regards
Abbas
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
[-- Attachment #2: Type: text/html, Size: 926 bytes --]
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-18 16:03 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc,
Paul Mackerras, Becky Bruce
In-Reply-To: <20060418145600.GE20234@pb15.lixom.net>
On Tue, Apr 18, 2006 at 09:56:00AM -0500, Olof Johansson wrote:
> On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
>
> > > understand now why you were talking about putting the code in the exit
> > > path on irc ... I don't like it that way.... Also, if you want to keep
> > > it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
> > > selected by platforms that can do it ?
> >
> > The config option makes sense.
>
> How about a CPU feature bit instead? That way it's possible to build a
> multiplatform kernel without getting the overhead on other platforms.
> 4 nops should be manageable?
DOH! I'm going blind, that's already there. So, Ben, you're unhappy
with nopping it out?
-Olof
^ permalink raw reply
* [PATCH] Remove stale iseries global
From: Olof Johansson @ 2006-04-18 16:25 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
Hi,
Not even the iSeries maintainer seems to have access to this legendary
piranha simulator. It adds a bit of ugliness in the common time init
code, and if it's no longer used we might as well be done with it and
remove the bloat.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/powerpc/kernel/time.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/time.c
+++ 2.6/arch/powerpc/kernel/time.c
@@ -76,7 +76,6 @@
/* keep track of when we need to update the rtc */
time_t last_rtc_update;
-extern int piranha_simulator;
#ifdef CONFIG_PPC_ISERIES
unsigned long iSeries_recal_titan = 0;
unsigned long iSeries_recal_tb = 0;
@@ -1010,10 +1009,7 @@ void __init time_init(void)
tb_to_ns_scale = scale;
tb_to_ns_shift = shift;
-#ifdef CONFIG_PPC_ISERIES
- if (!piranha_simulator)
-#endif
- tm = get_boot_time();
+ tm = get_boot_time();
write_seqlock_irqsave(&xtime_lock, flags);
Index: 2.6/arch/powerpc/platforms/iseries/mf.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/iseries/mf.c
+++ 2.6/arch/powerpc/platforms/iseries/mf.c
@@ -45,7 +45,6 @@
#include "setup.h"
-extern int piranha_simulator;
static int mf_initialized;
/*
@@ -658,7 +657,7 @@ static void mf_clear_src(void)
void __init mf_display_progress(u16 value)
{
- if (piranha_simulator || !mf_initialized)
+ if (!mf_initialized)
return;
if (0xFFFF == value)
@@ -1295,9 +1294,6 @@ __initcall(mf_proc_init);
*/
void iSeries_get_rtc_time(struct rtc_time *rtc_tm)
{
- if (piranha_simulator)
- return;
-
mf_get_rtc(rtc_tm);
rtc_tm->tm_mon--;
}
@@ -1316,9 +1312,6 @@ unsigned long iSeries_get_boot_time(void
{
struct rtc_time tm;
- if (piranha_simulator)
- return 0;
-
mf_get_boot_rtc(&tm);
return mktime(tm.tm_year + 1900, tm.tm_mon, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec);
Index: 2.6/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/iseries/setup.c
+++ 2.6/arch/powerpc/platforms/iseries/setup.c
@@ -80,9 +80,6 @@ extern void iSeries_pci_final_fixup(void
static void iSeries_pci_final_fixup(void) { }
#endif
-/* Global Variables */
-int piranha_simulator;
-
extern int rd_size; /* Defined in drivers/block/rd.c */
extern unsigned long embedded_sysmap_start;
extern unsigned long embedded_sysmap_end;
@@ -339,8 +336,6 @@ static void __init iSeries_init_early(vo
#ifdef CONFIG_SMP
smp_init_iSeries();
#endif
- if (itLpNaca.xPirEnvironMode == 0)
- piranha_simulator = 1;
/* Associate Lp Event Queue 0 with processor 0 */
HvCallEvent_setLpEventQueueInterruptProc(0, 0);
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jon Loeliger @ 2006-04-18 16:48 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1144938844.7777.16.camel@localhost.localdomain>
On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> > Actually, is this even an issue? can the LMB handle repeated
> > reservations?
>
> It can, but we were thinking about adding code to check and warn if
> reservations overlap, because it usually indicates a bug. Although
> that's probably ok in this case, as long as dtc gets fixed eventually.
> Another option would be to not warn for identical reservations.
> > >>>>> NOTE: that the dtc must also not generate the blob reservation
> > >>>>> entry.
> > >> looking passed my own world I see:
> > >> - iSeries: not reserving the blob at all
> > >
> > > That sounds right. I think having the kernel do it is definitely the
> > > right option.
OK, I'm back to reading the list and beginning to catch
up some here...
Let me see if I understand the consensus and direction:
1) DTC should NOT reserve its own blob space in the
memory map, as it does for generated ASM code now,
2) Kernel should reserve the blob space early so as
not to step on itself later,
3a) Kernel LMB handling should be modified to warn
for overlapping LMB reservations,
Except that Ben says:
3b) We should make lmb_reserve() of redudant/overlapping
entries become harmless I think. We need to be
backward compatible with earlier blobs that do
contain themselves in the reserve map.
I think we should interpret "harmless" to be "warn" and not
cause an error at this point in time.
I do not think we should have the blob generate its own
reservation because it is possible that some post-processing
(like U-Boot) can modify and extend it. Only after that can
the blob's true size be determined. (Sure, it could update
on the fly too... but double blah).
In all of this, I'm on deck for step 1) above.
jdl
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Will Schmidt @ 2006-04-18 17:31 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060418162553.GC26746@pb15.lixom.net>
On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> Hi,
>
> Not even the iSeries maintainer seems to have access to this legendary
> piranha simulator. It adds a bit of ugliness in the common time init
> code, and if it's no longer used we might as well be done with it and
> remove the bloat.
>
Yes, the piranha tools are no longer used with linux. I see no reason
why this needs to stay.
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
Acked-by: Will Schmidt willschm@us.ibm.com
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Michael Ellerman @ 2006-04-18 17:54 UTC (permalink / raw)
To: will_schmidt; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <1145381474.20493.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Tue, 2006-04-18 at 12:31 -0500, Will Schmidt wrote:
> On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not even the iSeries maintainer seems to have access to this legendary
> > piranha simulator. It adds a bit of ugliness in the common time init
> > code, and if it's no longer used we might as well be done with it and
> > remove the bloat.
>
> Yes, the piranha tools are no longer used with linux. I see no reason
> why this needs to stay.
So can we get rid of this from head_64.S as well? Or is that a different
debugger?
/*
* At offset 0x28 and 0x30 are offsets to the mschunks_map
* array (used by the iSeries LPAR debugger to do translation
* between physical addresses and absolute addresses) and
* to the pidhash table (also used by the debugger)
*/
.llong mschunks_map-KERNELBASE
.llong 0 /* pidhash-KERNELBASE SFRXXX */
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
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Ellerman @ 2006-04-18 18:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1145378886.5314.57.camel@cashmere.sps.mot.com>
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
> > On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> > > Actually, is this even an issue? can the LMB handle repeated
> > > reservations?
> >
> > It can, but we were thinking about adding code to check and warn if
> > reservations overlap, because it usually indicates a bug. Although
> > that's probably ok in this case, as long as dtc gets fixed eventually.
> > Another option would be to not warn for identical reservations.
>
> > > >>>>> NOTE: that the dtc must also not generate the blob reservation
> > > >>>>> entry.
>
> > > >> looking passed my own world I see:
> > > >> - iSeries: not reserving the blob at all
> > > >
> > > > That sounds right. I think having the kernel do it is definitely the
> > > > right option.
>
>
> OK, I'm back to reading the list and beginning to catch
> up some here...
>
> Let me see if I understand the consensus and direction:
>
> 1) DTC should NOT reserve its own blob space in the
> memory map, as it does for generated ASM code now,
>
> 2) Kernel should reserve the blob space early so as
> not to step on itself later,
>
> 3a) Kernel LMB handling should be modified to warn
> for overlapping LMB reservations,
>
> Except that Ben says:
>
> 3b) We should make lmb_reserve() of redudant/overlapping
> entries become harmless I think. We need to be
> backward compatible with earlier blobs that do
> contain themselves in the reserve map.
>
> I think we should interpret "harmless" to be "warn" and not
> cause an error at this point in time.
>
> I do not think we should have the blob generate its own
> reservation because it is possible that some post-processing
> (like U-Boot) can modify and extend it. Only after that can
> the blob's true size be determined. (Sure, it could update
> on the fly too... but double blah).
>
> In all of this, I'm on deck for step 1) above.
Nice summary :)
I'm up for 3a, we should make redundant/overlapping reserves "harmless",
by which I mean "not an error", but there should definitely be a warning
in the dmesg - as it will _usually_ indicate a bug.
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
* Re: please pull powerpc-merge.git
From: Andy Fleming @ 2006-04-18 18:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev Development
In-Reply-To: <17476.55180.340464.351828@cargo.ozlabs.ibm.com>
On Apr 18, 2006, at 07:11, Paul Mackerras wrote:
> Linus,
>
> Please do a pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
>
> to get the following powerpc bug-fixes.
What happened to the 85xx merge patches?
^ permalink raw reply
* [PATCH] powerpc: Make rtas console _much_ faster
From: Michael Ellerman @ 2006-04-18 18:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
ls -R /etc, which spits out about 27866 characters. The theoretical maximum
speed would be about 2.2 seconds, the current code takes ~50 seconds.
The core of the problem is that sometimes when the tty layer asks us to push
characters the firmware isn't able to handle some or all of them, and so
returns an error. The current code sees this and just returns to the tty code
with the buffer half sent.
There's the khvcd thread which will eventually wake up and try to push more
characters, that will usually work because the firmware's had time to push
the characters out. But the thread only wakes up every 10 milliseconds, which
isn't fast enough.
There's already code in the hvc_console driver to make the khvcd thread do
a "quick" loop, where it just calls yield() instead of sleeping. The only code
that triggered that behaviour was recently removed though, which I don't
quite understand.
Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
backend. With this patch the "benchmark" takes ~2.8 seconds.
I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
Thoughts?
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/char/hvc_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: cell/drivers/char/hvc_console.c
===================================================================
--- cell.orig/drivers/char/hvc_console.c
+++ cell/drivers/char/hvc_console.c
@@ -570,7 +570,7 @@ static int hvc_poll(struct hvc_struct *h
hvc_push(hp);
/* Reschedule us if still some write pending */
if (hp->n_outbuf > 0)
- poll_mask |= HVC_POLL_WRITE;
+ poll_mask |= HVC_POLL_WRITE | HVC_POLL_QUICK;
/* No tty attached, just skip */
tty = hp->tty;
^ permalink raw reply
* kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-18 19:19 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
For David Jander and Vitaly Bordug:
Regarding DMA allocation for CPM uarts, we had a similar issue with our
MPC857T and MPC885 boards. I think the real problem is that
bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
addresses allocated using dma_alloc_coherent(). We had a previous
discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
and virt_to_bus() should be deprecated. This is also recommended in the
whitepaper series that discussed porting device drivers from 2.4 to 2.6.
What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
as the base address for the cbd_bufaddr values in each of the
descriptors. The software, when accessing the DMA buffers, uses mem_addr
as the base, applying the same offset computed previously for the dma
addresses. This technique is used in other drivers all over 2.6.
This avoids the configuration dependencies on the conversion functions.
Ken Poole
kpoole@bos.mrv.com
[-- Attachment #2: Type: text/html, Size: 5214 bytes --]
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-18 18:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev@ozlabs.org, Michael Neuling
In-Reply-To: <1145383451.20176.9.camel@localhost.localdomain>
ok, to accept (1) means to accept (2).
AFAICT LMB is already handling overlaps.
So the first rough patch I sent should be sufficient.
On Apr 18, 2006, at 2:04 PM, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
>> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
>>> On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
>>>> Actually, is this even an issue? can the LMB handle repeated
>>>> reservations?
>>>
>>> It can, but we were thinking about adding code to check and warn if
>>> reservations overlap, because it usually indicates a bug. Although
>>> that's probably ok in this case, as long as dtc gets fixed
>>> eventually.
>>> Another option would be to not warn for identical reservations.
>>
>>>>>>>>> NOTE: that the dtc must also not generate the blob reservation
>>>>>>>>> entry.
>>
>>>>>> looking passed my own world I see:
>>>>>> - iSeries: not reserving the blob at all
>>>>>
>>>>> That sounds right. I think having the kernel do it is
>>>>> definitely the
>>>>> right option.
>>
>>
>> OK, I'm back to reading the list and beginning to catch
>> up some here...
>>
>> Let me see if I understand the consensus and direction:
>>
>> 1) DTC should NOT reserve its own blob space in the
>> memory map, as it does for generated ASM code now,
>>
>> 2) Kernel should reserve the blob space early so as
>> not to step on itself later,
>>
>> 3a) Kernel LMB handling should be modified to warn
>> for overlapping LMB reservations,
>>
>> Except that Ben says:
>>
>> 3b) We should make lmb_reserve() of redudant/overlapping
>> entries become harmless I think. We need to be
>> backward compatible with earlier blobs that do
>> contain themselves in the reserve map.
>>
>> I think we should interpret "harmless" to be "warn" and not
>> cause an error at this point in time.
>>
>> I do not think we should have the blob generate its own
>> reservation because it is possible that some post-processing
>> (like U-Boot) can modify and extend it. Only after that can
>> the blob's true size be determined. (Sure, it could update
>> on the fly too... but double blah).
>>
>> In all of this, I'm on deck for step 1) above.
>
> Nice summary :)
> I'm up for 3a, we should make redundant/overlapping reserves
> "harmless",
> by which I mean "not an error", but there should definitely be a
> warning
> in the dmesg - as it will _usually_ indicate a bug.
>
> 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
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-18 19:29 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, schmitz, debian-powerpc
Paul,
This new version of the patch breaks 32-bit arch/ppc builds. The changes
to the idle_6xx code are shared between architectures, but the entry.S
code and asm-offsets.c are not.
Here's a patch that puts the changes in arch/ppc as well. Builds and
boots on 834x (which is CONFIG_6xx).
-B
ppc: Fix powersave on arch/ppc
Fix asm_offsets.c and entry.S to work with the new power save code.
Changes in arch/powerpc needed to exist in arch/ppc as well since the
idle code is shared by both ppc and powerpc..
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
commit c9b42c4b6ad17aea51066604b70ea7ec399d2e45
tree 38642212d6396ecad721efca967ae1fc8924e096
parent c85f35d06479bf7cb5cfc7cda0ea218a23ed2dc4
author Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
committer Becky Bruce <becky.bruce@freescale.com> Tue, 18 Apr 2006 14:12:03 -0500
arch/ppc/kernel/asm-offsets.c | 1 +
arch/ppc/kernel/entry.S | 33 ++++++++++++++++-----------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/ppc/kernel/asm-offsets.c b/arch/ppc/kernel/asm-offsets.c
index 77e4dc7..cc7c4ae 100644
--- a/arch/ppc/kernel/asm-offsets.c
+++ b/arch/ppc/kernel/asm-offsets.c
@@ -134,6 +134,7 @@ main(void)
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index 5891ecb..1adc914 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -128,29 +128,26 @@ transfer_to_handler:
stw r12,4(r11)
#endif
b 3f
+
2: /* if from kernel, check interrupted DOZE/NAP mode and
* check for stack overflow
*/
+ lwz r9,THREAD_INFO-THREAD(r12)
+ cmplw r1,r9 /* if r1 <= current->thread_info */
+ ble- stack_ovf /* then the kernel stack overflowed */
+5:
#ifdef CONFIG_6xx
- mfspr r11,SPRN_HID0
- mtcr r11
-BEGIN_FTR_SECTION
- bt- 8,4f /* Check DOZE */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
-BEGIN_FTR_SECTION
- bt- 9,4f /* Check NAP */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
+ tophys(r9,r9) /* check local flags */
+ lwz r12,TI_LOCAL_FLAGS(r9)
+ mtcrf 0x01,r12
+ bt- 31-TLF_NAPPING,4f
#endif /* CONFIG_6xx */
.globl transfer_to_handler_cont
transfer_to_handler_cont:
- lwz r11,THREAD_INFO-THREAD(r12)
- cmplw r1,r11 /* if r1 <= current->thread_info */
- ble- stack_ovf /* then the kernel stack overflowed */
3:
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
- FIX_SRR1(r10,r12)
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r10
mtlr r9
@@ -158,7 +155,9 @@ transfer_to_handler_cont:
RFI /* jump to handler, enable MMU */
#ifdef CONFIG_6xx
-4: b power_save_6xx_restore
+4: rlwinm r12,r12,0,~_TLF_NAPPING
+ stw r12,TI_LOCAL_FLAGS(r9)
+ b power_save_6xx_restore
#endif
/*
@@ -167,10 +166,10 @@ transfer_to_handler_cont:
*/
stack_ovf:
/* sometimes we use a statically-allocated stack, which is OK. */
- lis r11,_end@h
- ori r11,r11,_end@l
- cmplw r1,r11
- ble 3b /* r1 <= &_end is OK */
+ lis r12,_end@h
+ ori r12,r12,_end@l
+ cmplw r1,r12
+ ble 5b /* r1 <= &_end is OK */
SAVE_NVGPRS(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
lis r1,init_thread_union@ha
^ permalink raw reply related
* Re: [PATCH] powerpc: Make rtas console _much_ faster
From: Olof Johansson @ 2006-04-18 19:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20060418185534.B1ADF679F0@ozlabs.org>
On Tue, Apr 18, 2006 at 08:55:29PM +0200, Michael Ellerman wrote:
> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?
I have an out-of-tree HVC backend here for a simple simulator console
(will never make it in-tree since it's never going to see other users). So
not that it really matters, but the patch is OK for that environment.
The only other case I can think of is if the backend really needs some
time to clear out data, if we end up spinning too much in the yield()
loop. POWER4 with HVC console is a possible candidate there, since all
partitions share a 19200bps line for consoles.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Assuming it's not an issue on POWER4 LPAR:
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: Port Linux w/ mbxboot to PPCBoot system
From: Jessica Chen @ 2006-04-18 19:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060415001224.D1551353A56@atlas.denx.de>
Thank you for your reply Wolfgang!
In u-boot-1.1.4 README "Where we come from" section, it says u-boot "provide
extended interface to Linux boot loader". Does it mean that there is still
some sort of boot loader in arch/ppc/coffboot/vmlinux.gz ? If yes, when
does it start? Does it boot the kernel?
To build u-boot, I will need to get the manual for MPC852 and check the
configurations in include/configs/TQM860L.h file.
I am trying to find the machine specific header file in linux-2.4.25
(include/asm-ppc/tqm8xx.h file in linux-2.4.4) which should have the same
definition of structure bd_info as in include/asm-ppc/u-boot.h. And you
recommend using linux-2.4 instead of linux-2.6 on your website.
So am I heading the right directions here? Because the u-boot README
doesn't have the new directories and filenames, I am a little confused.
Thanks again,
Jessica
> > I am new to embedded system, I am studying ppcboot-1.1.5 and linux
> > kernel-2.4.4 that comes with an mpc852 base board, we want to modify it
in
>
> Both PPCBoot and Linux 2.4.4 are *hoplessly* obsolete. It may be ok
> to study this to understand the workings, but please don't even dream
> of using it for any current work.
>
> > the future. In the build process, they use the zImage.initrd
> > (arch/ppc/mbxboot/zvmlinux.initrd) instead of the raw Linux kernel image
>
> Somebody didn't know what he was doing, it seems.
>
> > since ppcboot is already running, what happens when I boot the kernel
that
> > has old boot loader code in arch/ppc/mbxboot? Will some parameters be
> > overwritten? If not, why?
>
> The Linux bootstrap loader code (arch/ppc/mbxboot) will ignore the
> parameteres passed by U-Boot, will set up is own (hardwired), and
> duplicate some of the things that PPCboot did or would do.
>
> > I am very tempted to follow the README to re-build the kernel with
only
> > vmlinux.gz and port it, but I don't want to create any un-recoverable
> > results. So I am here to seek advice, maybe this is something obvious
to
> > many people.
>
> Don't change anything. Look at it, then drop it. Start using current
> code, i. e. a recent version of U-Boot and a recent Linux kernel.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Jack Steiner @ 2006-04-18 19:56 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060418130015.28928.10163.sendpatchset@skynet>
On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
> This is V3 of the patchset to size zones and memory holes in an
...
FYI, I applied the patches to a recent kernel & booted on a large
SGI system. No problem aside from what I assume is a very large number
of debug messages.
------
Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
Number of logical nodes in system = 512
Number of memory chunks in system = 512
SAL 2.9: SGI SN2 version 1.10
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
512 CPUs available, 512 CPUs total
MCA related initialization done
SGI SAL version 1.10
add_active_range(0, 25168900, 25235456): New
add_active_range(0, 25236375, 25419776): New
add_active_range(0, 27262976, 27516927): New
add_active_range(0, 29360128, 29614080): New
add_active_range(1, 92277760, 92528640): New
...
add_active_range(511, 34322242024, 34322242047): New
add_active_range(511, 34322243072, 34322243417): New
add_active_range(511, 34322243432, 34322243460): New
add_active_range(511, 34322243488, 34322243500): New
Virtual mem_map starts at 0xa0007e407d270000
free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
free_area_init_nodes(): find_min_pfn = 25168900
Dumping sorted node map
entry 0: 0 25168900 -> 25235456
entry 1: 0 25236375 -> 25419776
entry 2: 0 27262976 -> 27516927
entry 3: 0 29360128 -> 29614080
entry 4: 1 92277760 -> 92528640
entry 5: 1 94371840 -> 94625792
entry 6: 1 96468992 -> 96722944
...
entry 1536: 511 34321989632 -> 34322242001
entry 1537: 511 34322242016 -> 34322242022
entry 1538: 511 34322242024 -> 34322242047
entry 1539: 511 34322243072 -> 34322243417
entry 1540: 511 34322243432 -> 34322243460
entry 1541: 511 34322243488 -> 34322243500
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
__absent_pages_in_range(0, 68719476736, 68719476736) = 0
__absent_pages_in_range(0, 68719476736, 34322243584) = 0
__absent_pages_in_range(0, 34322243584, 34322243584) = 0
__absent_pages_in_range(0, 25168900, 68719476736) = 3687320
...
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
__absent_pages_in_range(511, 25168900, 68719476736) = 3687485
__absent_pages_in_range(511, 68719476736, 68719476736) = 0
__absent_pages_in_range(511, 68719476736, 34322243584) = 0
__absent_pages_in_range(511, 34322243584, 34322243584) = 0
Built 512 zonelists
Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
(essentially the same numbers as with a kernel w/o the patches)
McKinley Errata 9 workaround not needed; disabling it
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V3
From: Mel Gorman @ 2006-04-18 20:27 UTC (permalink / raw)
To: Jack Steiner
Cc: davej, tony.luck, Linux Memory Management List, ak, bob.picco,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20060418195644.GA30911@sgi.com>
On Tue, 18 Apr 2006, Jack Steiner wrote:
> On Tue, Apr 18, 2006 at 02:00:15PM +0100, Mel Gorman wrote:
>> This is V3 of the patchset to size zones and memory holes in an
> ...
>
>
>
> FYI, I applied the patches to a recent kernel & booted on a large
> SGI system.
Very cool, thanks for testing. I'm glad to see the assumptions related to
the size of node_map held up for a large machine.
> No problem aside from what I assume is a very large number
> of debug messages.
>
The debug messages are all in patch 7/7 and will be dropped before I try
and push this to -mm. The patch was included here in case a machine failed
to boot so I could figure out what went wrong.
>
> ------
> Linux version 2.6.17-tony (steiner@attica) (gcc version 4.1.0 (SUSE Linux)) #5 SMP PREEMPT Tue Apr 18 14:01:54 CDT 2006
> EFI v1.10 by INTEL: SALsystab=0x6002c51df0 ACPI 2.0=0x6002c51ee0
> Number of logical nodes in system = 512
> Number of memory chunks in system = 512
> SAL 2.9: SGI SN2 version 1.10
> SAL Platform features: ITC_Drift
> SAL: AP wakeup using external interrupt vector 0x12
> No logical to physical processor mapping available
> ACPI: Local APIC address c0000000fee00000
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> 512 CPUs available, 512 CPUs total
> MCA related initialization done
> SGI SAL version 1.10
> add_active_range(0, 25168900, 25235456): New
> add_active_range(0, 25236375, 25419776): New
> add_active_range(0, 27262976, 27516927): New
> add_active_range(0, 29360128, 29614080): New
> add_active_range(1, 92277760, 92528640): New
> ...
> add_active_range(511, 34322242024, 34322242047): New
> add_active_range(511, 34322243072, 34322243417): New
> add_active_range(511, 34322243432, 34322243460): New
> add_active_range(511, 34322243488, 34322243500): New
> Virtual mem_map starts at 0xa0007e407d270000
> free_area_init_nodes(68719476736, 68719476736, 34322243584, 34322243584)
> free_area_init_nodes(): find_min_pfn = 25168900
> Dumping sorted node map
> entry 0: 0 25168900 -> 25235456
> entry 1: 0 25236375 -> 25419776
> entry 2: 0 27262976 -> 27516927
> entry 3: 0 29360128 -> 29614080
> entry 4: 1 92277760 -> 92528640
> entry 5: 1 94371840 -> 94625792
> entry 6: 1 96468992 -> 96722944
> ...
> entry 1536: 511 34321989632 -> 34322242001
> entry 1537: 511 34322242016 -> 34322242022
> entry 1538: 511 34322242024 -> 34322242047
> entry 1539: 511 34322243072 -> 34322243417
> entry 1540: 511 34322243432 -> 34322243460
> entry 1541: 511 34322243488 -> 34322243500
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> __absent_pages_in_range(0, 68719476736, 68719476736) = 0
> __absent_pages_in_range(0, 68719476736, 34322243584) = 0
> __absent_pages_in_range(0, 34322243584, 34322243584) = 0
> __absent_pages_in_range(0, 25168900, 68719476736) = 3687320
> ...
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> __absent_pages_in_range(511, 25168900, 68719476736) = 3687485
> __absent_pages_in_range(511, 68719476736, 68719476736) = 0
> __absent_pages_in_range(511, 68719476736, 34322243584) = 0
> __absent_pages_in_range(511, 34322243584, 34322243584) = 0
> Built 512 zonelists
> Kernel command line: BOOT_IMAGE=net0:jfs/tonys ro hashdist=1 dhash_entries=2097152 ihash_entries=2097152 rhash_entries=2097152 thash_entries=2097152 console=ttySG0,38400n8 kdb=on noprobe root=/dev/sda5
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour dummy device 80x25
> Memory: 4639378784k/4655642784k available (7021k code, 16279040k reserved, 4361k data, 736k init)
> (essentially the same numbers as with a kernel w/o the patches)
> McKinley Errata 9 workaround not needed; disabling it
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Remove stale iseries global
From: Will Schmidt @ 2006-04-18 19:02 UTC (permalink / raw)
To: michael; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <1145382862.20176.5.camel@localhost.localdomain>
On Tue, 2006-04-18 at 19:54 +0200, Michael Ellerman wrote:
> On Tue, 2006-04-18 at 12:31 -0500, Will Schmidt wrote:
> > On Tue, 2006-04-18 at 11:25 -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Not even the iSeries maintainer seems to have access to this legendary
> > > piranha simulator. It adds a bit of ugliness in the common time init
> > > code, and if it's no longer used we might as well be done with it and
> > > remove the bloat.
> >
> > Yes, the piranha tools are no longer used with linux. I see no reason
> > why this needs to stay.
>
> So can we get rid of this from head_64.S as well? Or is that a different
> debugger?
It's likely the same (piranha) debugger. I'm not aware of any other
debuggers that would be involved here.
What I dont know is if this offset to the mschunks_map array is also
used by the hypervisor for some non debug purposes. If iSeries
continues to work without it, then it can probably go too.
Just be sure that PPC_EARLY_DEBUG_ISERIES will continue to work for
getting info out of the system. :-)
> /*
> * At offset 0x28 and 0x30 are offsets to the mschunks_map
> * array (used by the iSeries LPAR debugger to do translation
> * between physical addresses and absolute addresses) and
> * to the pidhash table (also used by the debugger)
> */
> .llong mschunks_map-KERNELBASE
> .llong 0 /* pidhash-KERNELBASE SFRXXX */
>
> cheers
>
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5, 4 -- no sound?")
From: Paul Collins @ 2006-04-19 4:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <1145397523.4705.94.camel@localhost.localdomain>
Hi Ben,
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2006-04-18 at 17:20 +0200, Michael Schmitz wrote:
>> > > Here a trace at boot from the sound driver :
>> >
>> > I think that bug happens if the sound driver loads before i2c-powermac.
>>
>> i2c-keywest is still request-module()d in 2.6.17-rc1, FWIW.
>>
>> Regarding other sound breakage with 2.6.17-rc1, I traced that to
>>
>> machine_is(powermac)
>>
>> returning zero in sound/ppc/pmac.c:snd_pmac_detect() when loading
>> snd-powermac. The OSS driver spits -ENODEV as well on loading so I'd
>> suspect the same thing here.
>>
>> machine_is boils down to a comparison machine_id == &mach_powermac, is
>> that sort of thing illegal after kernel init?
>
> Totally untested patch, please let me know if it helps:
Results in the following.
arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[1]: *** [arch/powerpc/platforms/powermac] Error 2
make: *** [arch/powerpc/platforms] Error 2
It looks like the EXPORT_SYMBOL() needs to be after the definition.
However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
define_machine(powermac) and now sound works for me with my original
I2C_POWERMAC=y SND_POWERMAC=m configuration.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Benjamin Herrenschmidt @ 2006-04-19 5:19 UTC (permalink / raw)
To: Paul Collins
Cc: [ATR]Dj-Death, linuxppc-dev, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <87r73u19b1.fsf@briny.internal.ondioline.org>
> arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> make: *** [arch/powerpc/platforms] Error 2
>
> It looks like the EXPORT_SYMBOL() needs to be after the definition.
>
> However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> define_machine(powermac) and now sound works for me with my original
> I2C_POWERMAC=y SND_POWERMAC=m configuration.
Yup, Paul has a working patch already, will be in 2.6.17 soonish.
Cheers,
Ben.
^ permalink raw reply
* I want to use SCC3 as ethernet with SMC1 as console(mpc8xx)
From: 김영남 @ 2006-04-19 6:40 UTC (permalink / raw)
To: linuxppc-embedded
First of all, I am sorry for my poor english.
I have mpc850 custom board with followings:
SMC1 - console
SMC2 - uart
SCC2 - ethernet
I want to use SCC2 and SCC3 as ethernet(two ethernet interfaces).
As many web sites and mailing lists describe, I knew that SMC patch is
required because SMC1 and SCC3 share parameter ram.
I have DENX 2.4.25 kernel and this kernel works fine except using SCC3
as ethernet.
When apply "USE_SMC_PATCH" in arch/ppc/8xx_io/micropatch.c, kernel hang
and reset without any messages.(using u-boot 1.1.4)
I want to know that when I use "USE_SMC_PATCH", which source file is
modified and how to modify source file to use SMC1 as console.
Could you tell me useful information about that?
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: Wojciech Kromer @ 2006-04-19 7:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604062238.17972.antonio.dibacco@aruba.it>
Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> Hi,
>
> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that receives
> the new rootfs from a web interface and then tries to write it in the flash.
> While overwriting the old cramfs, the CGI will continue to work? something
> weird could happen?
>
Generally it's not a good idea to override working filesystem ( I've
tried to do it once).
You can have two separate copies of filesystem, one to work with, and
another to overwrite, it requires more flash.
Another way is working in initrd, it requires more RAM.
You can also use jffs2 or jffs3 (experimental) to have read-write
filesystem, and change applications only, not whole filesystem (be
carefull with changing busybox or libraries!)
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-19 11:13 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <1144842264.443ce818d6822@webmail.televes.com:443>
Well,
I have tested two different approaches which has been confirmed
to be already working on MPC82xx boards.
One, from Paul Bilke, is based on modifiying printk to service
the WDT and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:
asmlinkage int printk(const char *fmt, ...)
{
va_list args;
int r;
force_wdt_reload();
[...]
}
#define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)
void force_wdt_reload(void)
{
unsigned short *swsr_ptr = (unsigned short *)ioremap(SWSR_ADDR,0x2);
(*swsr_ptr) = (unsigned short) 0x556c;
(*swsr_ptr) = (unsigned short) 0xaa39;
}
Paul has reported changing printk works for him on several MPC82xx boards.
Second one is from Mike Rapoport from Compulab. Is the heartbeat
method. I have added and additional call in m82xx_board_setup()
which should reset the WDT for the first time in setup_arch():
static __inline__ void reset_8260_watchdog(void)
{
cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0x556c;
cpm2_immr->im_siu_conf.siu_82xx.sc_swsr = 0xaa39;
}
void __init
m82xx_board_setup(void)
{
volatile cpm2_map_t *immap = cpm2_immr;
reset_8260_watchdog();
ppc_md.heartbeat = m82xx_heartbeat;
ppc_md.heartbeat_reset = HZ/2;
ppc_md.heartbeat_count = 1;
}
Mike has reported the heartbeat method is working for him
on MPC8247 and MPC8271 boards with kernel 2.6.12.3.
I have tested both in a MCP8248 based board, with kernel
2.6.15 and u-boot 1.1.4 and I have no success. I can see
the __log_buf after the reset caused by de WDT and there
are several printk's done. I have put printk's to the
reset_8260_watchdog(), and I can see them also, so I
should suppose it is executed, but the board keeps reseting.
Furthermore, u-boot is doing OK the WDT job (with changes done
from Compulab).
I have dissasambled that, and for example:
c01c93b8 <m82xx_board_setup>:
c01c93b8: 3d 40 c0 1e lis r10,-16354
c01c93bc: 38 00 55 6c li r0,21868
c01c93c0: 81 2a 81 8c lwz r9,-32372(r10)
c01c93c4: 3d 09 00 01 addis r8,r9,1
c01c93c8: b0 08 00 0e sth r0,14(r8)
c01c93cc: 81 68 0d 50 lwz r11,3408(r8)
c01c93d0: 81 2a 81 8c lwz r9,-32372(r10)
c01c93d4: 75 60 08 00 andis. r0,r11,2048
c01c93d8: 38 00 aa 39 li r0,-21959
c01c93dc: 3d 29 00 01 addis r9,r9,1
c01c93e0: b0 09 00 0e sth r0,14(r9)
c01c93e4: 41 82 00 44 beq- c01c9428 <m82xx_board_setup+0x70>
[...]
which looks OK for me (but I am not an expert).
So, could someone give me some guideline about what could
be happening?. Should I downgrade to 2.6.12.3 and test?
Is the WDT being reloaded at least one time and then
failing to reset? Some idea on how to debug that?
Thanks
Alex BASTOS
P.S. The __log_buf
3c353e4c 696e7578 20766572 73696f6e <5>Linux version
20322e36 2e313520 28616c65 62617340 2.6.15 (alebas@
54523339 32292028 67636320 76657273 xxxx) (gcc vers
696f6e20 332e332e 32292023 33392050 ion 3.3.2) #39 P
5245454d 50542054 75652041 70722031 REEMPT Tue Apr 1
38203135 3a32353a 33392043 45535420 8 15:25:39 CEST
32303036 0a3c363e 54656c65 76657320 2006.<6>Televes
446f4338 32343820 436f6d70 75746572 XXX8248 Computer
2d6f6e2d 4d6f6475 6c652070 6f72740a -on-Module port.
3c373e4f 6e206e6f 64652030 20746f74 <7>On node 0 tot
616c7061 6765733a 20313633 38340a3c alpages: 16384.<
373e2020 444d4120 7a6f6e65 3a203136 7> DMA zone: 16
33383420 70616765 732c204c 49464f20 384 pages, LIFO
62617463 683a330a 3c373e20 20444d41 batch:3.<7> DMA
3332207a 6f6e653a 20302070 61676573 32 zone: 0 pages
2c204c49 464f2062 61746368 3a300a3c , LIFO batch:0.<
373e2020 4e6f726d 616c207a 6f6e653a 7> Normal zone:
20302070 61676573 2c204c49 464f2062 0 pages, LIFO b
61746368 3a300a3c 373e2020 48696768 atch:0.<7> High
4d656d20 7a6f6e65 3a203020 70616765 Mem zone: 0 page
732c204c 49464f20 62617463 683a300a s, LIFO batch:0.
3c343e42 75696c74 2031207a 6f6e656c <4>Built 1 zonel
69737473 0a3c353e 4b65726e 656c2063 ists.<5>Kernel c
6f6d6d61 6e64206c 696e653a 20726f6f ommand line: roo
743d2f64 65762f72 616d3020 72772063 t=/dev/ram0 rw c
6f6e736f 6c653d74 74794350 4d0a3c35 onsole=ttyCPM.<5
3e596f75 20617265 20617420 4f6e650a >You are at One.
3c343e50 49442068 61736820 7461626c <4>PID hash tabl
6520656e 74726965 733a2035 31322028 e entries: 512 (
6f726465 723a2039 2c203831 00000000 order: 9, 81....
00000000 00000000 00000000 00000000 ................
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: David Jander @ 2006-04-19 9:28 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Kenneth Poole
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D3A5@bosmail.BOS.int.mrv.com>
Hi Kenneth,
On Tuesday 18 April 2006 21:19, Kenneth Poole wrote:
> Regarding DMA allocation for CPM uarts, we had a similar issue with our
> MPC857T and MPC885 boards. I think the real problem is that
> bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
> addresses allocated using dma_alloc_coherent(). We had a previous
> discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
> and virt_to_bus() should be deprecated. This is also recommended in the
> whitepaper series that discussed porting device drivers from 2.4 to 2.6.
You are right! I hadn't noticed the (implicit) use of virt_to_bus() in
cpm_uart_core.c. In the case that "((unsigned long)addr >= CPM_ADDR)", the
address isn't translated, that's why the uart keeps sending lots of 0xff's
instead of real data: There is empty flash at that adress (after 0xff100000)!
This also explains why the system hangs when I set CONFIG_CONSISTENT_START to
0xfd100000, because then the CPM will access unadressed space.
Vitaly: Is it true that your ADS boards both have
IMMAP_ADDR < CONFIG_CONSISTENT_START ?
That would explain why those do work.
On the PQ2's dma_alloc_coherent(), behaves differently, so they might also
work.
In fact, bus_to_virt(), which is also used, does nothing more than adding
KERNELBASE to the address, so a!=bus_to_virt(virt_to_bus(a)) if 'a' is
obtained by anything other than kmalloc(). So if 'a' is obtained from
dma_alloc_coherent(), will bus_to_virt(virt_to_bus(a)) at least yield a
correctly mapped virtual address?
I am asking, because line 263 of cpm_uart_core.c does exactly this, and it
smells ;-)
> What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
> dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
> as the base address for the cbd_bufaddr values in each of the
> descriptors. The software, when accessing the DMA buffers, uses mem_addr
> as the base, applying the same offset computed previously for the dma
> addresses. This technique is used in other drivers all over 2.6.
Sounds like the correct thing to do, but do you (by any chance) have a patch
for this change, to share?
Thanks a lot to everyone for their comments and help.
Greetings,
--
David Jander
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Vitaly Bordug @ 2006-04-19 10:21 UTC (permalink / raw)
To: David Jander; +Cc: Kenneth Poole, linuxppc-embedded
In-Reply-To: <200604191128.50138.david.jander@protonic.nl>
On Wed, 19 Apr 2006 11:28:49 +0200
David Jander <david.jander@protonic.nl> wrote:
>
> Hi Kenneth,
>
> On Tuesday 18 April 2006 21:19, Kenneth Poole wrote:
> > Regarding DMA allocation for CPM uarts, we had a similar issue with our
> > MPC857T and MPC885 boards. I think the real problem is that
> > bus_to_virt() and virt_to_bus() don't work on 8xx platforms for
> > addresses allocated using dma_alloc_coherent(). We had a previous
> > discussion Pantelis Antoniou and he agreed that the use of bus_to_virt()
> > and virt_to_bus() should be deprecated. This is also recommended in the
> > whitepaper series that discussed porting device drivers from 2.4 to 2.6.
>
> You are right! I hadn't noticed the (implicit) use of virt_to_bus() in
> cpm_uart_core.c. In the case that "((unsigned long)addr >= CPM_ADDR)", the
> address isn't translated, that's why the uart keeps sending lots of 0xff's
> instead of real data: There is empty flash at that adress (after 0xff100000)!
> This also explains why the system hangs when I set CONFIG_CONSISTENT_START to
> 0xfd100000, because then the CPM will access unadressed space.
>
> Vitaly: Is it true that your ADS boards both have
> IMMAP_ADDR < CONFIG_CONSISTENT_START ?
> That would explain why those do work.
> On the PQ2's dma_alloc_coherent(), behaves differently, so they might also
> work.
>
Right.
> In fact, bus_to_virt(), which is also used, does nothing more than adding
> KERNELBASE to the address, so a!=bus_to_virt(virt_to_bus(a)) if 'a' is
> obtained by anything other than kmalloc(). So if 'a' is obtained from
> dma_alloc_coherent(), will bus_to_virt(virt_to_bus(a)) at least yield a
> correctly mapped virtual address?
> I am asking, because line 263 of cpm_uart_core.c does exactly this, and it
> smells ;-)
>
Well I was aware about no-good there, but since it works fine with my HW, and no other complaints, there were no reason to overhaul.
> > What we did was use dma_alloc_coherent() in cpm_uart_cpm1.c, saving
> > dma_addr in the pinfo structure. The in cpm_uart_core.c, we use dma_addr
> > as the base address for the cbd_bufaddr values in each of the
> > descriptors. The software, when accessing the DMA buffers, uses mem_addr
> > as the base, applying the same offset computed previously for the dma
> > addresses. This technique is used in other drivers all over 2.6.
>
> Sounds like the correct thing to do, but do you (by any chance) have a patch
> for this change, to share?
>
If there is any code to reference, I'd appreciate it (and merge to the driver).
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-19 14:59 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded list
In-Reply-To: <005401c663a9$e1fd8930$6401a8c0@CHUCK2>
Mark,
>
> I haven't been following this closely, but are you sure it's a WDT
> reset? You can tell from the Reset Status Register (RSR).
> u-boot prints out a decode of this register, which also clears the
> bits, so you have to go by the printout when u-boot starts to see
> why the last reset occurred.
U-boot is reporting the Watchdog reset. You can see:
U-Boot 1.1.4 (Apr 11 2006 - 14:39:01)
MPC8272 Reset Status: Software Watchdog, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 400 MHz
Board: Televes XXX8248
Watchdog enabled
>
> Just trying to help brainstorm...
>
> Mark Chambers
>
Thanks,
Alex Bastos
^ 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