* New fs_enet driver : filling platform_data
From: Laurent Pinchart @ 2006-04-18 13:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to use the new fs_enet FCC ethernet driver (drivers/net/fs_enet)
with an Embedded Planet EP8284 board (LXT971A phy).
I don't know how/where to fill the platform_data structure that the
mii-bitbang driver uses. Could anyone give me some help, or point me to a
sample implementation for a similar platform ?
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: New fs_enet driver : filling platform_data
From: Vitaly Bordug @ 2006-04-18 13:13 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200604181509.38713.laurent.pinchart@tbox.biz>
On Tue, 18 Apr 2006 15:09:38 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> I'm trying to use the new fs_enet FCC ethernet driver (drivers/net/fs_enet)
> with an Embedded Planet EP8284 board (LXT971A phy).
>
> I don't know how/where to fill the platform_data structure that the
> mii-bitbang driver uses. Could anyone give me some help, or point me to a
> sample implementation for a similar platform ?
>
I have posted recently fs_enet driver update to the list - (FS_ENET: use PAL for mii management)
- you'll find needed platform info updates for 8272ads and 866 ads in the patch. I am going to push it rather shortly, after I'll correct some minor issues appeared.
> Best regards,
>
> Laurent Pinchart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: CF card connection to PPC CPUs
From: Travis B. Sawyer @ 2006-04-18 12:48 UTC (permalink / raw)
To: Andriy Korud; +Cc: linuxppc-embedded
In-Reply-To: <60E856FD577CC04BA3727AF4122D3F160106FDDB@3bit.vector.com.pl>
Andriy Korud wrote:
>Hi,
>Does anybody has experience in connecting CF card to PPC (especially
>44x) CPU directly via EBC bus?
>I see how this can be done in TrueIDE mode, but unfortunately our
>application requires hot swap capability.
>
>
>
Andriy:
We've done the direct connect route on a couple of our platforms
(formerly Sandburst Metrobox).
Unfortunately, as you state, you lose HS caps.
We used two chip selects, and connected the bus as follows:
EBC Addr 28:30 <-> CF Addr 2:0
EBC Data CF Data
8 15
9 14
10 13
11 12
12 11
13 10
14 9
15 8
0 7
1 6
2 5
3 4
4 3
5 2
6 1
7 0
/OE & /CSEL are pulled down
/REG & /WE are pulled up.
Check out Das U-Boot Sandburst Metrobox (include/configs/METROBOX.h) for
usage info.
We essentially used a technote/appnote from Toshiba (that I can't find
right now).
Good luck,
travis
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Vitaly Bordug @ 2006-04-18 13:22 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604181446.08673.david.jander@protonic.nl>
On Tue, 18 Apr 2006 14:46:08 +0200
David Jander <david.jander@protonic.nl> wrote:
>
> Hi all,
>
> Situation 1: MPC852T with SMC1 as uart/console, and SCC3/SCC4 as additional
> uarts. SMC1 works fine, but SCC3/4 don't. On transmission attempt, both UARTS
> transmit a byte 0x00 instead of what was intended to be transmitted.\
>
> Situation 2: The same as above, but console on either SCC3 or SCC4. The uart
> being initialized as console works ok, the other two don't.
>
Well, existing code works just fine on 885ads and 866ads, that use SMC1 and SMC2 as UARTs.
> I'm pretty sure the following is wrong, but I can't seem to fix it either.
> This seems to apply for both PQ and PQ2 type uarts:
> from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
That's wrong - cpm_uart_cpm1.c applies to PQ only...
>
> ....
> if (is_con) {
> /* was hostalloc but changed cause it blows away the */
> /* large tlb mapping when pinning the kernel area */
> mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
> dma_addr = 0;
> } else
> mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> GFP_KERNEL);
>
> ....
> pinfo->dp_addr = dp_offset;
> pinfo->mem_addr = mem_addr;
> pinfo->dma_addr = dma_addr;
>
> pinfo->rx_buf = mem_addr;
> ....
>
> AFAICS pinfo->rx_buf is the pointer to a buffer as seen from the CPM's point
> of view, so it should hold a physical adress, not a virtual address. It seems
> to me that it should be more like this (lines marked with ** are changed):
>
> ....
> if (is_con) {
> /* was hostalloc but changed cause it blows away the */
> /* large tlb mapping when pinning the kernel area */
> mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
> ** dma_addr = mem_addr;
> } else
> mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> GFP_KERNEL);
>
> ....
> pinfo->dp_addr = dp_offset;
> pinfo->mem_addr = mem_addr;
> pinfo->dma_addr = dma_addr;
>
> ** pinfo->rx_buf = dma_addr;
> ....
>
> This does not work either, but I suspect this is a different problem, because
> if I change dma_alloc_coherent() for something using kmalloc() and then
> dma_addr=virt_to_phys(mem_addr), uarts begin to work, but trasmit mixed old
> and new data from the buffers due to the cache getting in the way. At least
> reception seems to work ok then.
> So, why doesn't dma_alloc_coherent() work the way one would expect?
> Obviously, changing "if (is_con)" into "if (1)" all three uarts work
> correctly, but I guess we want to save on DP_RAM usage if ever possible.
>
> What else is wrong here?
>
Well, since it works on other boards, and kmalloc stuff seems to sorta work as well, then I guess reason is screwed DMA thing for your board. Check/alter CONFIG_CONSISTENT_* things and see if it will help.
And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are never used actually in the code, hereby there is no difference what values they contain...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: New fs_enet driver : filling platform_data
From: Laurent Pinchart @ 2006-04-18 13:40 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060418171317.5f9db046@vitb.ru.mvista.com>
Hi Vitaly,
> I have posted recently fs_enet driver update to the list - (FS_ENET: use
> PAL for mii management) - you'll find needed platform info updates for
> 8272ads and 866 ads in the patch. I am going to push it rather shortly,
> after I'll correct some minor issues appeared.
Thanks. Which tree is your patched based on ? It doesn't apply cleanly against
2.6.16.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ppc64-soft-reset-fixes
From: David Wilder @ 2006-04-18 14:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, fastboot
In-Reply-To: <20060417231235.36546cb6.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
Andrew Morton wrote:
>David Wilder <dwilder@us.ibm.com> wrote:
>
>
>> - For the crash scenario, when a CPU hangs with interrupts disabled and
>> the other CPUs panic or user invoked kdump boot using sysrq-c. In this
>> case, the hung CPU can not be stopped and causes the kdump boot not
>> successful. This case can be treated as complete system hang and asks
>> the user to activate soft-reset if all secondary CPUs are not stopped.
>>
>>
>
>It breaks `make allmodconfig':
>
>arch/powerpc/kernel/built-in.o(.toc+0x2a00): In function `PPC64_CACHES':
>: undefined reference to `kexec_crash_image'
>
>
>
>
Sorry for the confusion ppc64-soft-reset-fixes.patch patch is depended
on another patch (kdump-image-rm-static.patch). Please see my earlier
posting at http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021956.html.
My apologies for not restating this dependency in yesterdays posting. I
have attached the earlier patch in this email.
Again both ppc64-soft-reset-fixes.patch and kdump-image-rm-static.patch
must be applied to keep from breaking the build.
Regards
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: kdump-image-rm-static.patch --]
[-- Type: text/x-patch, Size: 1027 bytes --]
--- 2617-rc1/kernel/kexec.c.orig 2006-04-05 13:27:53.000000000 -0700
+++ 2617-rc1/kernel/kexec.c 2006-04-05 13:27:43.000000000 -0700
@@ -903,7 +903,7 @@ static int kimage_load_segment(struct ki
* that to happen you need to do that yourself.
*/
struct kimage *kexec_image = NULL;
-static struct kimage *kexec_crash_image = NULL;
+struct kimage *kexec_crash_image = NULL;
/*
* A home grown binary mutex.
* Nothing can wait so this mutex is safe to use
@@ -1042,7 +1042,6 @@ asmlinkage long compat_sys_kexec_load(un
void crash_kexec(struct pt_regs *regs)
{
- struct kimage *image;
int locked;
@@ -1056,12 +1055,11 @@ void crash_kexec(struct pt_regs *regs)
*/
locked = xchg(&kexec_lock, 1);
if (!locked) {
- image = xchg(&kexec_crash_image, NULL);
- if (image) {
+ if (kexec_crash_image) {
struct pt_regs fixed_regs;
crash_setup_regs(&fixed_regs, regs);
machine_crash_shutdown(&fixed_regs);
- machine_kexec(image);
+ machine_kexec(kexec_crash_image);
}
xchg(&kexec_lock, 0);
}
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: David Jander @ 2006-04-18 14:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060418172244.25eefcd3@vitb.ru.mvista.com>
On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
>[..]
> Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> SMC2 as UARTs.
Interesting.
> > I'm pretty sure the following is wrong, but I can't seem to fix it
> > either. This seems to apply for both PQ and PQ2 type uarts:
> > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
>
> That's wrong - cpm_uart_cpm1.c applies to PQ only...
I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as
the cpm_uart_cpm1.c.
>[...]
> Well, since it works on other boards, and kmalloc stuff seems to sorta work
> as well, then I guess reason is screwed DMA thing for your board.
> Check/alter CONFIG_CONSISTENT_* things and see if it will help.
I did not touch de defaults. What are the rules to change them? What do I have
to look out for?
CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was
using MTD (currently disabled) since flash is at physical adress
0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to
that same virtual adress? How's that supposed to work then?
I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes
when I write to the serial port :-(
> And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> never used actually in the code, hereby there is no difference what values
> they contain...
Argh. Code looks obviously broken, but since it isn't used, it just works.
That is not good! We should fix that either way then.
Thanks,
--
David Jander
^ permalink raw reply
* scc in hdlc mode linux-2.4 device driver for MPC8247
From: Nethi venkata Subbarao @ 2006-04-18 14:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am new to embedded systems software and planning
to write a scc device driver for MPC8247 processor. It
will be very useful if someone can provide me sample
scc driver code for MPC8247. currently using denk's
linuxppc-2.4.20. I had written test driver but it was
hanging SMC1 console.
Thanks in advance
nethi.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Vitaly Bordug @ 2006-04-18 14:21 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604181605.40642.david.jander@protonic.nl>
On Tue, 18 Apr 2006 16:05:40 +0200
David Jander <david.jander@protonic.nl> wrote:
> On Tuesday 18 April 2006 15:22, Vitaly Bordug wrote:
> >[..]
> > Well, existing code works just fine on 885ads and 866ads, that use SMC1 and
> > SMC2 as UARTs.
>
> Interesting.
>
And for PQ2 I can add 8260 , PQ2fads and 8272ads that had no issues with current driver
> > > I'm pretty sure the following is wrong, but I can't seem to fix it
> > > either. This seems to apply for both PQ and PQ2 type uarts:
> > > from drivers/serial/cpm_uart/cpm_uart_cpm1.c (line 190):
> >
> > That's wrong - cpm_uart_cpm1.c applies to PQ only...
>
> I know. cpm_uart_cpm2.c contains the same code, so it should be as broken as
> the cpm_uart_cpm1.c.
pq2 are cache-coherent, so there are no such troubles in there. And allocation routine is different of course.
>
> >[...]
> > Well, since it works on other boards, and kmalloc stuff seems to sorta work
> > as well, then I guess reason is screwed DMA thing for your board.
> > Check/alter CONFIG_CONSISTENT_* things and see if it will help.
>
> I did not touch de defaults. What are the rules to change them? What do I have
> to look out for?
> CONFIG_CONSISTENT_START = 0xff100000 and I suspect a problem here if I was
> using MTD (currently disabled) since flash is at physical adress
> 0xfe000000-0xffffffff on my board. Isn't MTD going to io_remap that area to
> that same virtual adress? How's that supposed to work then?
> I changed CONFIG_CONSISTENT_START to 0xfd100000 and now the system freezes
> when I write to the serial port :-(
>
Unfortunately, I know nothing where the correct thing should be pulled from...
But the problem lies in dma stuff from what I can say.
> > And, try to just replace dma_alloc_.. with kmalloc (not changing rx_buf
> > etc.) and reproduce the same behavior you had. BTW, rx_buf and tx_buf are
> > never used actually in the code, hereby there is no difference what values
> > they contain...
>
> Argh. Code looks obviously broken, but since it isn't used, it just works.
> That is not good! We should fix that either way then.
The overhaul is on the way, I'll put the cleanup of the unused stuff together with other changes.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-18 14:56 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc, Becky Bruce
In-Reply-To: <17476.34830.897083.360572@cargo.ozlabs.ibm.com>
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?
-Olof
^ permalink raw reply
* 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
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