* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Olof Johansson @ 2006-07-18 22:38 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060718212913.GB3091@w-mikek2.ibm.com>
On Tue, Jul 18, 2006 at 02:29:13PM -0700, Mike Kravetz wrote:
> 88 1046 108106 109322
[...]
> 104 1 1040 1061
Heh. Shouldn't PURR/TB be <= 1 at all times? :-) I bet this is because
they're not sampled at exactly the same time, etc.
Maybe recoding it to assembly so you can do mftb and mfspr right after
each other, and do the arithmetics/stores later could help. Inline asm
might be sufficient.
-Olof
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Mike Kravetz @ 2006-07-18 23:18 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060718223425.GB5238@pb15.lixom.net>
On Tue, Jul 18, 2006 at 05:34:25PM -0500, Olof Johansson wrote:
> As I said before, SPRN_PURR doesn't exist on all architecture versions
> that supports hypervisor mode.
Thanks!
I assume checking must be done at run time via something like,
if (cpu_has_feature(CPU_FTR_PURR))
Also assume that it would make sense to do this determination at
initialization/boot time and put the result in the statistic data
structure. In this way we would know it is in the same cache line
we are updating with other stats. Or, should cur_cpu_spec->cpu_features
be 'sufficiently hot' to make this a non-issue?
--
Mike
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Eugene Surovegin @ 2006-07-18 23:35 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060718110350.28445.qmail@web36614.mail.mud.yahoo.com>
On Tue, Jul 18, 2006 at 04:03:50AM -0700, Parav Pandit wrote:
> Hi,
>
> We allocate memory for DMA operation on PCI device using pci_alloc_constistent().
>
> I want to know how this function is boil down to the actual instruction which locks the page in the RAM so that it cannot be paged out and dma can do its work.
This is trivial - you can start with looking at the implementation.
>
> Can anybody tell me which instructions do we use to set this page entry in TLB and page table?
> What bit gets set in the PTE for this?
Why do you need this page in TLB?
In general you don't have to worry about _any_ memory you allocated in
the kernel to be paged out.
--
Eugene
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-19 3:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17597.19430.983453.919592@cargo.ozlabs.ibm.com>
On Wed, Jul 19, 2006 at 07:00:22AM +1000, Paul Mackerras wrote:
> Mike Kravetz writes:
> > A small update from the last version. By popular demand, both
> > wall time (mftb) and cpu cycles(PURR) are collected for each call.
> > It is interesting to see these two values side by side in the
> > output files.
>
> Did you see the patch from Anton that I posted a week or so ago, which
> reduces the number of plpar_hcall_* functions? I'd rather the
> instrumentation stuff was based on that.
Agreed. I missed the patch from last week, but saw the one from Anton
that was posted today. Future instrumentation patches will assume this
change.
> My other comment is this: wouldn't it actually turn out simpler if we
> read the timebase (and PURR, if we really want to do that too) in the
> assembly code that implements plpar_hcall_*?
I'll give that a try. My assembly skills are a bit rusty, so it may
take a little longer to produce something.
--
Mike
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Olof Johansson @ 2006-07-19 3:33 UTC (permalink / raw)
To: Mike Kravetz; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <20060718231815.GC3091@w-mikek2.ibm.com>
On Tue, Jul 18, 2006 at 04:18:15PM -0700, Mike Kravetz wrote:
> I assume checking must be done at run time via something like,
> if (cpu_has_feature(CPU_FTR_PURR))
If you do it in the hcall asm instead (like Paulus suggested), then it's
better to use BEGIN_FTR_SECTION/END_FTR_SECTION() around it, that way
the PURR reads just get nopped out instead of adding tests and branches.
> Also assume that it would make sense to do this determination at
> initialization/boot time and put the result in the statistic data
> structure. In this way we would know it is in the same cache line
> we are updating with other stats. Or, should cur_cpu_spec->cpu_features
> be 'sufficiently hot' to make this a non-issue?
If you use the FTR_SECTION stuff then it'll be taken care of
automatically at boot time. Doing that from C is messy, I don't think
anyone has had reason to do it before.
-Olof
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Parav Pandit @ 2006-07-19 4:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060718233554.GA27549@gate.ebshome.net>
--- Eugene Surovegin <ebs@ebshome.net> wrote:
> > We allocate memory for DMA operation on PCI
> device using pci_alloc_constistent().
> >
> > I want to know how this function is boil down to
> the actual instruction which locks the page in the
> RAM so that it cannot be paged out and dma can do
> its work.
>
> This is trivial - you can start with looking at the
> implementation.
>
[Parav]
I did it, but after reaching __alloc_pages() its
getting difficult to understand.
Here is the sequence:
pci_alloc_consistent()
-> __get_free_pages()
->alloc_pages(gfp_mask, order)
->alloc_pages_current()
-> __alloc_pages()
It does something with zones. Looks like zone memory
pages are locked in the beginning.
Still could not figure out the instuctions for page
locking.
> >
> > Can anybody tell me which instructions do we use
> to set this page entry in TLB and page table?
> > What bit gets set in the PTE for this?
>
> Why do you need this page in TLB?
[Parav] No, I don't want. I just wanted to see the
code for locking inside TLB or in page table.
>
> In general you don't have to worry about _any_
> memory you allocated in
> the kernel to be paged out.
>
[Parav] As driver writer, I agree I don't need to, but
to better understand the system I am eager to do that.
Regards,
Parav
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: kernel memory map/usage/holes?
From: Sonny Rao @ 2006-07-19 4:47 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <44BBEDE1.3040004@nortel.com>
On Mon, Jul 17, 2006 at 02:06:57PM -0600, Chris Friesen wrote:
>
> I've got a Maple board with 4GB of memory running a modified 2.6.10
> kernel. When it boots, I see the following in the logs:
>
>
> Top of RAM: 0x180000000, Total RAM: 0x100000000
> On node 0 totalpages: 1048576
> DMA zone: 1048576 pages, LIFO batch:16
> Normal zone: 0 pages, LIFO batch:1
> HighMem zone: 0 pages, LIFO batch:1
>
>
> Then a bit later, I see:
>
>
> Memory: 4006976k/6291456k available (3408k kernel code, 2284124k
> reserved, 1656k data, 448k bss, 220k init)
>
>
>
> 1048576 pages works out to 4194304kB, so what happened to the 187328kB
> that is the difference between the "Total RAM" and "Memory:" lines?
> We've got an app that wants as much memory as possible, so I need to
> explain where this 183MB of memory is being used.
I think it's part of the "reserved" category, which includes the MMU
hashtable. I'd guess that's where it is.
Sonny
^ permalink raw reply
* RE: reboot on PQ2FADS board.
From: Li Yang-r58472 @ 2006-07-19 5:06 UTC (permalink / raw)
To: Lei Sun, linuxppc-embedded
In-Reply-To: <f9a7e7a80607172040lcf0a280x5df9f44d10a0b7d6@mail.gmail.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of Lei Sun
> Sent: Tuesday, July 18, 2006 11:41 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: reboot on PQ2FADS board.
>=20
> Hi:
> I have linux 2.4.30 runnning on this board, the "reboot -f"
> command cause machine check and kernel ooops. The problem seems in
> the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
> passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> the warm start address, I changed it to 0xFF800100, that's where the
> u-boot's _start_warm lives, I have verified that address by typing "g
> ff800100" in u-boot console, which cause the board reset.
Are you sure ff800100 is _start_warm lives? In latest u-boot
_start_warm is at
EXC_OFF_SYS_RESET + 0x10. In your case, that will be 0xff800110.
Please try
with the correct address.
> I assume the m8260_gorom has been heavily tested for other
> boards. I wonder if anyone got a PQ2FADS-VR board that has the similar
> problem? I am not familar with the assembly code for PPC. Any
> suggestions?
>=20
> Thanks
> lei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Linux bin Commands download
From: Li Yang-r58472 @ 2006-07-19 5:31 UTC (permalink / raw)
To: none none, linuxppc-dev
In-Reply-To: <20060718123527.75952.qmail@web26204.mail.ukl.yahoo.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of none
> none
> Sent: Tuesday, July 18, 2006 8:35 PM
> To: linuxppc-dev@ozlabs.org
> Subject: Linux bin Commands download
>=20
> Hi
> I would like to download precompiled linux commands
> and programs for powerPC but i cannot find any
> binaries anyware. Are there any links?
You can find rpm at http://rpmfind.net. And there are also a couple of
powerpc distributions out there.
> thanks in advance
> sotirakopoulos andreas
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add wrappers
From: Mike Kravetz @ 2006-07-19 3:50 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060719033300.GA9451@pb15.lixom.net>
On Tue, Jul 18, 2006 at 10:33:00PM -0500, Olof Johansson wrote:
> If you use the FTR_SECTION stuff then it'll be taken care of
> automatically at boot time. Doing that from C is messy, I don't think
> anyone has had reason to do it before.
Ok, sounds like a good reason for assembly. I'll dust off the books. :)
--
Mike
^ permalink raw reply
* RE: [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-19 6:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <41AD230F-91E8-442A-B9F9-9892D14BEF12@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, July 18, 2006 9:53 PM
> To: Li Yang-r58472
> Cc: Dan Malek; linuxppc-dev@ozlabs.org;
linux-usb-devel@lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
>=20
> [snip]
>=20
> >> Well, I think there is a coupling that exists between whatever your
> >> boot rom is and the kernel. If you are trying to optimize boot
time
> >> I'd say one thing you would want is to avoid multiple writing the
> >> same configuration registers.
> >>
> >> I dont have an issue if a fixed function board decides to do these
> >> things in their kernel init instead of their boot rom. I however,
> >> don't want thousand and one config options to support all the
various
> >> ways one can configure the Freescale board.
> >
> > We won't have the thousand and one config options, making use of the
> > device
> > tree. So this is not a problem.
>=20
> I'm talking about opening the door to a ton of options, not that we
> have them now. For example, your patch doesnt handle the USB PHYs if
> they are on the MDS instead of the SYS board. It doesn't handle
> setting SCCR properly for different frequency choices. I'm concerned
> about where to draw the line because of all the ways a user can
> configure the MDS board.
My understanding is that in embedded world only this kind of versatile
development boards needs to have Linux port in mainstream kernel. A
fixed function customer board used in embedded product will never get
into kernel source.
The reasons for Freescale to provide this kind of boards are: first,
verify functions on chip; second, demonstrate chip functions to
customer; third, validate customer application on reference board;
forth, help customer to build their own product by cutting down the
board and software.
Doing that, we do need some configure options to demonstrate main
functions. But there won't be too many options to confuse the user.
Only key working modes are needed. In your example, I think making USB
PHYs configurable for MDS is reasonable, but for SCCR it isn't as it is
well commented in code and is not likely to be modified. Keep in mind
that our only purpose is making customers easier and faster in
developing their own products.
>=20
> - kumar
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Wolfgang Denk @ 2006-07-19 6:33 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net>
In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
>
> > command cause machine check and kernel ooops. The problem seems in
> > the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
> > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > the warm start address, I changed it to 0xFF800100, that's where the
> > u-boot's _start_warm lives, I have verified that address by typing "g
> > ff800100" in u-boot console, which cause the board reset.
>
> Are you sure ff800100 is _start_warm lives? In latest u-boot
Trying to jump to some boot rom address is IMHO always a bad approach
to reboot a system. You should always try to cause a reset condition
for the CPU, and thus for all the associated hardware. On 8xx / 8260
systems this is usually done by going through a machine check. We
have the following code in our linuxppc_2_4_devel tree, which works
on ALL 8260 systems, no matter whioch boot loder they use:
static void
m8260_restart(char *cmd)
{
__volatile__ unsigned char dummy;
ulong msr;
cli();
volatile immap_t *immap = (immap_t *) IMAP_ADDR;
immap->im_clkrst.car_rmr = 1; /* Checkstop Reset enable */
/* Interrupts and MMU off */
__asm__ __volatile__ ("mfmsr %0":"=r" (msr):);
msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
__asm__ __volatile__ ("mtmsr %0"::"r" (msr));
dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
printk("Restart failed\n");
for (;;);
}
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
^ permalink raw reply
* Linux controlling Hardware-Tasks on FPGA
From: Josef Angermeier @ 2006-07-19 7:31 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
anyone else out there using or wanting to use Linux to control the
reconfiguration of a FPGA ? - Do you use dynamic partial reconfiguration
too ? - If so how did you design the relevant software coarsely ?
thanks in advance,
Josef
^ permalink raw reply
* Re: [gmail] Linux bin Commands download
From: Marc Leeman @ 2006-07-19 7:21 UTC (permalink / raw)
To: none none; +Cc: linuxppc-dev
In-Reply-To: <20060718123527.75952.qmail@web26204.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
> I would like to download precompiled linux commands
> and programs for powerPC but i cannot find any
> binaries anyware. Are there any links?
> thanks in advance
You probably haven't been looking very hard (or at all). See e.g.
http://www.debian.org
--
greetz, marc
It's not Kansas, and you're way too homely to be Auntie Em, but... Come
here, Toto.
Crichton - That Old Black Magic
scorpius.homelinux.org 2.6.17 #2 PREEMPT Thu Jun 22 07:18:33 CEST 2006 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] force 64bit mode in fwnmi handlers to workaround firmware bugs
From: Olaf Hering @ 2006-07-19 8:34 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060522164111.GA14462@suse.de>
The firmware of POWER4 and JS20 systems does not switch the cpu to 64bit
mode when the registered system_reset and machine_check handlers get called.
If a 32bit process runs on that cpu at the time of the event, the cpu
remains in 32bit mode. xmon and kdump can not deal with it, the result is
an error like 'Bad kernel stack pointer fff2aad0 at 3200'.
xmon just loses some register info, but booting the kdump kernel usually fails.
Both handlers are not hot paths. Duplicate the EXCEPTION_PROLOG_PSERIES macro
and add two instructions to switch to 64bit:
li r11,5;
rldimi r10,r11,61,0;
Signed-off-by: Olaf Hering <olh@suse.de>
---
arch/powerpc/kernel/head_64.S | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
Index: linux-2.6.18-rc2/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.18-rc2.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6.18-rc2/arch/powerpc/kernel/head_64.S
@@ -191,6 +191,37 @@ exception_marker:
ori reg,reg,(label)@l; /* virt addr of handler ... */
#endif
+/*
+ * Equal to EXCEPTION_PROLOG_PSERIES, except that it forces 64bit mode.
+ * The firmware calls the registered system_reset_fwnmi and
+ * machine_check_fwnmi handlers in 32bit mode if the cpu happens to run
+ * a 32bit application at the time of the event.
+ * This firmware bug is present on POWER4 and JS20.
+ */
+#define EXCEPTION_PROLOG_PSERIES_FORCE_64BIT(area, label) \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,area+EX_R9(r13); /* save r9 - r12 */ \
+ std r10,area+EX_R10(r13); \
+ std r11,area+EX_R11(r13); \
+ std r12,area+EX_R12(r13); \
+ mfspr r9,SPRN_SPRG1; \
+ std r9,area+EX_R13(r13); \
+ mfcr r9; \
+ clrrdi r12,r13,32; /* get high part of &label */ \
+ mfmsr r10; \
+ /* force 64bit mode */ \
+ li r11,5; /* MSR_SF_LG|MSR_ISF_LG */ \
+ rldimi r10,r11,61,0; /* insert into top 3 bits */ \
+ /* done 64bit mode */ \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label) \
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
#define EXCEPTION_PROLOG_PSERIES(area, label) \
mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
std r9,area+EX_R9(r13); /* save r9 - r12 */ \
@@ -604,14 +635,14 @@ slb_miss_user_pseries:
system_reset_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common)
+ EXCEPTION_PROLOG_PSERIES_FORCE_64BIT(PACA_EXGEN, system_reset_common)
.globl machine_check_fwnmi
.align 7
machine_check_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common)
+ EXCEPTION_PROLOG_PSERIES_FORCE_64BIT(PACA_EXMC, machine_check_common)
#ifdef CONFIG_PPC_ISERIES
/*** ISeries-LPAR interrupt handlers ***/
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-19 13:14 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D050B55@zch01exm20.fsl.freescale.net>
On Jul 19, 2006, at 1:30 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Tuesday, July 18, 2006 9:53 PM
>> To: Li Yang-r58472
>> Cc: Dan Malek; linuxppc-dev@ozlabs.org;
> linux-usb-devel@lists.sourceforge.net
>> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
>>
>> [snip]
>>
>>>> Well, I think there is a coupling that exists between whatever your
>>>> boot rom is and the kernel. If you are trying to optimize boot
> time
>>>> I'd say one thing you would want is to avoid multiple writing the
>>>> same configuration registers.
>>>>
>>>> I dont have an issue if a fixed function board decides to do these
>>>> things in their kernel init instead of their boot rom. I however,
>>>> don't want thousand and one config options to support all the
> various
>>>> ways one can configure the Freescale board.
>>>
>>> We won't have the thousand and one config options, making use of the
>>> device
>>> tree. So this is not a problem.
>>
>> I'm talking about opening the door to a ton of options, not that we
>> have them now. For example, your patch doesnt handle the USB PHYs if
>> they are on the MDS instead of the SYS board. It doesn't handle
>> setting SCCR properly for different frequency choices. I'm concerned
>> about where to draw the line because of all the ways a user can
>> configure the MDS board.
>
> My understanding is that in embedded world only this kind of versatile
> development boards needs to have Linux port in mainstream kernel. A
> fixed function customer board used in embedded product will never get
> into kernel source.
This is an incorrect assumption. Its more often that people dont
post their ports to the Linux kernel for acceptance. We will accept
any port that is willing to work with the community. for example
> The reasons for Freescale to provide this kind of boards are: first,
> verify functions on chip; second, demonstrate chip functions to
> customer; third, validate customer application on reference board;
> forth, help customer to build their own product by cutting down the
> board and software.
>
> Doing that, we do need some configure options to demonstrate main
> functions. But there won't be too many options to confuse the user.
> Only key working modes are needed. In your example, I think making
> USB
> PHYs configurable for MDS is reasonable, but for SCCR it isn't as
> it is
> well commented in code and is not likely to be modified. Keep in mind
> that our only purpose is making customers easier and faster in
> developing their own products.
That's fine, however Freescale should figure out what the "common"
modes of usage are before hand and document them. Then the community
can have a sense of the scope of what is needed and how to try to
best accomplish that, and if anything is missing.
I disagree about the SCCR, I think its very reasonable for a customer
to set the frequencies of their MDS board to match what their
production system is going to be, which means the SCCR would need to
be modified to match.
At the end of the day we will get some version of your patch into the
kernel. I just wanted to get some discussion on how we handle the
reference boards that are extremely configurable.
- kumar
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Lei Sun @ 2006-07-19 14:12 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060719063317.86A66352681@atlas.denx.de>
Hi :
I tried your approach last ight, (in fact I copied part of the
do_reboot() code from u-boot and put it in m8260_restart() function in
the kernel). The only difference is the first line,
volatile immap_t *immap = (immap_t *) IMAP_ADDR;
in my case it is
volatile immap_t * immap = cpm2_immr;
I am using different source tree.
it simply hangs, rather then reset.
On 7/19/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
> >
> > > command cause machine check and kernel ooops. The problem seems in
> > > the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
> > > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > > the warm start address, I changed it to 0xFF800100, that's where the
> > > u-boot's _start_warm lives, I have verified that address by typing "g
> > > ff800100" in u-boot console, which cause the board reset.
> >
> > Are you sure ff800100 is _start_warm lives? In latest u-boot
>
> Trying to jump to some boot rom address is IMHO always a bad approach
> to reboot a system. You should always try to cause a reset condition
> for the CPU, and thus for all the associated hardware. On 8xx / 8260
> systems this is usually done by going through a machine check. We
> have the following code in our linuxppc_2_4_devel tree, which works
> on ALL 8260 systems, no matter whioch boot loder they use:
>
> static void
> m8260_restart(char *cmd)
> {
> __volatile__ unsigned char dummy;
> ulong msr;
>
> cli();
> volatile immap_t *immap = (immap_t *) IMAP_ADDR;
>
> immap->im_clkrst.car_rmr = 1; /* Checkstop Reset enable */
>
> /* Interrupts and MMU off */
> __asm__ __volatile__ ("mfmsr %0":"=r" (msr):);
>
> msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
> __asm__ __volatile__ ("mtmsr %0"::"r" (msr));
>
> dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
>
> printk("Restart failed\n");
> for (;;);
> }
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> If a group of N persons implements a COBOL compiler, there will be
> N-1 passes. Someone in the group has to be the manager. - T. Cheatham
>
^ permalink raw reply
* MPC8260 SCC UART hardware flow control
From: Laurent Pinchart @ 2006-07-19 15:18 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I was wondering if anyone had implemented hardware flow control support in the
cpm_uart driver. If not, I would appreciate pointers regarding how to do so.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: Linux controlling Hardware-Tasks on FPGA
From: David Hawkins @ 2006-07-19 16:15 UTC (permalink / raw)
To: Josef Angermeier; +Cc: linuxppc-embedded
In-Reply-To: <44BDDFD2.9040702@cs.fau.de>
> anyone else out there using or wanting to use Linux to control the
> reconfiguration of a FPGA ? - Do you use dynamic partial reconfiguration
> too ? - If so how did you design the relevant software coarsely ?
Hi Josef,
If you are talking 'partial reconfiguration' then I guess you
are discussing Xilinx devices.
I use Altera devices in my designs. However, this solution could
work for you.
Generally an FPGA is configured, and I assume reconfigured,
by writing the configuration file to a specific set of pins
on the device. Altera devices have passive serial programming
and fast passive parallel programming (and other options).
In my current design I will create either a /dev entry or
use a /sys/firmware type interface that when opened
initializes the programming logic, and then writes whatever
bytes are written to the filesystem node to the programming
interface, eg. so the following will program the FPGA
dd if=firmware.bin of=/dev/fpga
If I get a programming error, then the driver can just return
-EIO, and I'm pretty sure dd will report the error. I plan
to use this approach as I can then buffer the data from user-space
into a kernel buffer, and then setup a DMA controller to
write to the device node. This will ensure that burst transactions
are used (to a system controller FPGA sitting on the local bus
of a PowerQUICC II Pro).
The alternative is to implement mmap() for the region containing
your programming interface control registers, and then just
bit- or byte-bang the programming interface. However, if the
serial interface is slow, then you could turn your 100MHz+ CPU
into a 1MHz- CPU. Linux sometimes has trouble with this
(I've seen the x86 kernel lose ticks when performing lots of
PCI I/O, so now use DMA when its available - which for x86
is basically never, so you have to depend on the adapter board).
Hope that gives you some ideas.
Regards
Dave
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Mathieu Deschamps @ 2006-07-19 16:41 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607190712v362c3e1ei7e85003041a25e35@mail.gmail.com>
Hi,
On Wednesday 19 July 2006 16:12, Lei Sun wrote:
> Hi :
> I tried your approach last ight, (in fact I copied part of the
> do_reboot() code from u-boot and put it in m8260_restart() function in
> the kernel). The only difference is the first line,
> volatile immap_t *immap = (immap_t *) IMAP_ADDR;
> in my case it is
> volatile immap_t * immap = cpm2_immr;
> I am using different source tree.
> it simply hangs, rather then reset.
>
[...]
Give a try to :
startaddr = 0xff000104;
--
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-07-19 16:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3140C9D90FB6D911ABD7000F206DC92603D6E0FC@zhk08exm40.ap.freescale.net>
Hi Jeffrey,
> I have done the PCI config cycle under u-boot. This is very simple
and > able to find the PEX EP attached to the MPC8548.
> In this log, it is reading a pair of MPC8548E connected together
using > PEX.
> Please see the log below:
[ ... ]
thanks for sharing this piece of information.
I will investigate if this matches the way it is done in the kernel.
Thanks,
Florian
Ho Jeffrey-r26191 schrieb:
> Hi Florian,
>
>
> U-Boot 1.1.4 (Apr 12 2006 - 11:40:53)
>
> CPU: 8548_E, Version: 1.1, (0x80390011)
> Core: e500v2, Version: 1.0, (0x80210010)
> Clock Configuration:
> CPU:1333 MHz, CCB: 533 MHz,
> DDR: 266 MHz, LBC: 33 MHz
> L1: D-cache 32 kB enabled
> I-cache 32 kB enabled
>
> Board: MPC85xx Processor Card Rev. A.
> -- Boot Flash is U30
>
> SRIO: X4 2.5Gbps
> PEX : X4 2.5Gbps
> PCI1: 32 bit, async
> PCI2: disabled
> I2C: ready
> DRAM: Initializing
> DDR: 256 MB
> FLASH: 16 MB
> L2 cache 512KB: enabled
> In: serial
> Out: serial
> Err: serial
> Net: eTSEC0: PHY is Marvell 88E1111S (1410cc1)
> eTSEC1: PHY is Realtek RTL821x (1cc912)
> eTSEC2: PHY is Marvell 88E1111S (1410cc1)
> eTSEC3: PHY id ffffffff is not supported!
> eTSEC0, eTSEC1, eTSEC2 [PRIME], eTSEC3
> eTSEC0 & eTSEC1 in Reduce mode
> eTSEC2 & eTSEC3 in Reduce mode
> Hit any key to stop autoboot: 0
> MPC8548E_Rev1.1=> mm e000a000 <-setup command register
> e000a000: 8000f800 ? 80000004 Bus master, SERR, Memory space
> e000a004: 02001000 ? 06011000
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set secondary bus num = 1
> e000a000: 80000004 ? 80000018 Subordinate bus num = 3
> e000a004: 00000000 ? 00010300
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Check PEX agent ID
> e000a000: 80000018 ? 80010000
> e000a004: 57191200 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent BAR0 (PEXCSRBAR)
> e000a000: 80010010 ? 80010010 PEXCSRBAR = 0x80000000
> e000a004: 00000000 ? 00000080 This is the PCI address space
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent command register
> e000a000: 80010014 ? 80010004 Bus master, SERR, Memory space
> e000a004: 00001000 ? 06011000
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=>
> mw e000ac20 00080000; <-Set TAR = 0x80000000 (PCI address space)
> mw e000ac24 0; <-Set 32:64bit TAR = 0x0 (PCI address space)
> mw e000ac28 000a0000; <-Set WBA = 0xa0000000 (ECM, e500 address space)
> mw e000ac30 8004401A <-Set normal R/W, enable Outbound window
> MPC8548E_Rev1.1=>
> MPC8548E_Rev1.1=>
> MPC8548E_Rev1.1=> mm e000a000 <-check PEX agent BAR0 if written
> e000a000: 80010010 ?
> e000a004: 00000080 ? .
> MPC8548E_Rev1.1=> md a0000000 <-read PEX agent CCSRBAR address use 0xa0000000
> a0000000: 000ff700 00000000 00000000 00000000 ................
> a0000010: 00000000 00000000 00000000 00000000 ................
> a0000020: 00000000 00000000 00000000 00000000 ................
> a0000030: 00000000 00000000 00000000 00000000 ................
> a0000040: 00000000 00000000 00000000 00000000 ................
> a0000050: 00000000 00000000 00000000 00000000 ................
> a0000060: 00000000 00000000 00000000 00000000 ................
> a0000070: 00000000 00000000 00000000 00000000 ................
> a0000080: 00000000 00000000 00000000 00000000 ................
> a0000090: 00000000 00000000 00000000 00000000 ................
> a00000a0: 00000000 00000000 00000000 00000000 ................
> a00000b0: 00000000 00000000 00000000 00000000 ................
> a00000c0: 00000000 00000000 00000000 00000000 ................
> a00000d0: 00000000 00000000 00000000 00000000 ................
> a00000e0: 00000000 00000000 00000000 00000000 ................
> a00000f0: 00000000 00000000 00000000 00000000 ................
>
> Regards,
> Jeffrey Ho
> Freescale Semiconductor HK Ltd
> Tel: 852-26668050
>
>
>> -----Original Message-----
>> From:
>> linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.
>> org] On Behalf Of Florian Boelstler
>> Sent: Monday, June 26, 2006 6:48 PM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
>>
>> Hi,
>>
>> I am currently working on a MPC8548-based development system.
>> Linux kernel version is 2.6.11 with patches delivered from
>> Freescale (BSP MPC8548CDS 02/24/2006).
>>
>> Kernel configuration contains a warning message for CONFIG_PEX:
>> "This requires hardware modification to work correctly if
>> your CPU version < 2.0 and will break the PCI bus. [...]"
>>
>> I was wondering whether enabling PCIe makes PCI bus
>> functionality unusable at all (including kernel functionality
>> for detecting devices behind a transparent PCI-to-PCI bridge).
>>
>> Our setup connects a transparent PLX8516 PCI-to-PCI bridge to
>> the PCIe port of the MPC8548 daughter board. Behind that
>> bridge is another PCIe capable device.
>> MPC8548 is configured to run as PCIe host mode.
>>
>> When trying to lookup the PCIe devices using lspci I can only
>> see the PPC itself and the bridge.
>> However I cannot see the device(s) behind the bridge.
>>
>> Is there another method for detecting PCI(e) devices?
>> Is "BSP MPC8548CDS 02/24/2006" the latest version
>> corresponding to that hardware?
>>
>> Thanks in advance,
>>
>> Florian
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
^ permalink raw reply
* Re: Kexec initial registers
From: Milton Miller @ 2006-07-19 17:17 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <1152911297.23037.109.camel@localhost.localdomain>
On Jul 14, 2006, at 5:08 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
>> This is what I have so far:
The processor will be in real mode. (well, whatever that means for book-e)
>>
>> r3: address of device tree blob
>> r4: address that kernel was loaded
mostly, see below.
>> r5: not OF (=0)
>
> Correct and that's all that should be needed
>
For single processor.
>> r13: local_paca address (0?)
>
> You shouldn't have to care about r13 at all, it should be set by the
> kernel before it's used. If not, please let us know as that means
> there
> is a bug :)
[Mike Ellerman pointed out a recient patch to fix one such bug].
>> Did I miss the document on this?
The documentation for kexec is in arch/powerpc/kernel/misc_64.S in
the middle of kexec_sequence. The documentation for the kernel
entry point is at Documentation/powerpc/booting-without-of.txt.
On the elected master cpu, r4 contains the address of the entry point.
Upon leaving the kernel r3 contains the hardware cpu identifier, and
r5 is 0 to say there is no of interface and r3 and r4 are valid. Both
v2wrap.S and the standard kexec-tools purgatory code store this value
in the device tree struct header and point r3 to the header, which is
the entry requirement for the linux kerne.
To support multi-processor, 256 (0x100) bytes are copied from the
the entry point to address 0, r3 is loaded with the hardware cpu
id corresponding to a node in the device tree and execution of the
slave is at absolute 0x60. Other than being in real mode, the only
state on a slave is r3 and the entry point. Specifically, r4 and
r5 are unspecified.
Unfornately current kexec-tools doesnn't seem to look for the entry
point of the loaded image and assumes it is offset zero. This
creates an unfornate limitation that I only reciently discovered,
and I hope someone will fix it.
Today the register state only applies to the PowerPC 64 bit interface;
the game cube is the only 32 bit port I am aware of and they didn't
have the multi-processor issues. However, I expect 32 bit will
gain this interface well.
Histoory and Background:
Kexec went though some design refinement before it got merged. Part
of this was standardization of the kexec syscall across architectures,
and part was moving to a concept of intermediate wrappers the any
environment setup required for the loaded image. Kexec is supposed
to be able to load any code image and not be tied to loading a linux
kernel. It was declared the only state at the end of the kernel
kexec implmentation would be specified memory contents, processor
execution mode, and entry point. The entry point and memory contents
are specified explictily; the execution mode defaults to the
instruction set and word size of the kernel. While any elf platform
type can be specified the kernel will likely only support only one
(native) or possbly two (for example a 32 bit mode may be added).
All setup of registers, mmu, and any other environment shall be
done in code inserted by kexec-tools or other kexec_load callers.
In kexec-tools, this stage is called purgatory (its neither here
nor there); it is built seperately and embedded in the kexec program.
The register state and other enviornmental parameters is patched
into the image before calling the kexec_load syscall).
Unfornately this would not quite meet the needs of multiprocessor
PowerPC platforms. On x86 other processors have executed an interrupt
disabled halt instruction and therefore are waiting for a NMI or
"init". Unlike x86, PowerPC does not guarantee a way to stop
execution of a processor. How to start a secondary cpu is platform
specific. Not all platforms have a park method that is reversable.
A way was needed to park the slaves. In addition, there is no cross
platform way to determine which cpu you are executing on.
I chose the method that the kernel already did between the prom
code and the main kernel to solve both problems. Copy 256 bytes
to zero, specifiy a second entry point of address 0x60 after the
copy, and specify r3 has the hardware id.
While having r3 point to the device-tree structure on the master
thread might seem to simplify the handoff, there were several
problems. First, there is no method to pass the address of the
structure to the kernel. I realized this was limiting to images
that wanted the kernel's device tree structure and not in the load
anything, setup the environment using code added to the memory image,
design point of kexec. Passing the the hardware identifier
was the minimum requirement. And passing it in r3 is the obvious
choice, both because that is what the slaves needed and it is the
first argument on many calling conventions.
Because branching to an arbitrary address requires loading
said address into a general purpose register I decided that specifing
that register would be r4 would have minimal impact to any code.
And specifiying r5 be zero was purely gratitious, but its one
instruction.
One other difference in the PowerPC 64 bit kexec is that, due to
the limited addressability of memory in real mode in partitions
(HV=0), the initial copy is done with the mmu using the base kernel
and therefore the destination memory can not overlap it or the mmu
page table. If an image requires memory in these areas to be
initialized, then some code must be added to purgatory; the linux
kernel already had the needed copy loop because of our interaction
with open firmware in prom_init.c and that was exploited. In
addition, pSeries tce tables and RTAS are protected.
milton
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-19 15:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <4856A73A-BB23-4850-A697-1CE7C385DE42@kernel.crashing.org>
On Jul 19, 2006, at 9:14 AM, Kumar Gala wrote:
> This is an incorrect assumption. Its more often that people dont
> post their ports to the Linux kernel for acceptance. We will
> accept any port that is willing to work with the community. for
> example
I agree. The customers of board ports I've done over the years
are always eager to get these into the public sources. It just
seems we run out of time during the pressure of trying to get
the products done, and they just issue them on CDs or for
download afterward.
Thanks.
-- Dan
^ permalink raw reply
* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-19 18:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: 'linuxppc-dev list'
In-Reply-To: <17597.8378.972640.464219@cargo.ozlabs.ibm.com>
On Wed, Jul 19, 2006 at 03:56:10AM +1000, Paul Mackerras wrote:
> A lot of compression and encryption algorithms, by their very nature,
> are very difficult to parallelize enough to get any significant
> improvement from altivec. I looked at SHA1 for instance, and the
> sequential dependencies in the computation are such that it is
> practically impossible to find a way to do 4 things in parallel. The
> sequential dependencies are of course a critical part of the way that
> SHA1 ensures that a small change in any part of the input data results
> in substantial changes in every byte of the output.
But perhaps, in principle, couldn't one run four independent streams
in parallel? Thus, for example, on an SSL-enabled web server, one
could service multiple encryption/decryption threads at once.
In practice, I don't beleive the infrastructure for that kind of
parallelism is in place. I'm struggling to find a reason to develop
that kind of infrastructure. Mumble something about Cell.
> I think that there are actually very few places in the kernel where we
> are doing something which is parallelizable, sufficiently
> compute-intensive, and not bound by memory bandwidth, to be worth
> using altivec.
Yes.
As to non-kernel applications, is there anything for GMP (the
Gnu Multi-Precision library, an arbitrary-precision math library)
on the Altivec? How aout the Cell?
--linas
^ permalink raw reply
* Re: AltiVec in the kernel
From: Paul Mackerras @ 2006-07-19 18:19 UTC (permalink / raw)
To: Linas Vepstas; +Cc: 'linuxppc-dev list'
In-Reply-To: <20060719181047.GL5905@austin.ibm.com>
Linas Vepstas writes:
> But perhaps, in principle, couldn't one run four independent streams
> in parallel? Thus, for example, on an SSL-enabled web server, one
> could service multiple encryption/decryption threads at once.
Generally that would work. If one had 4 separate streams to compute a
SHA1 of, one could do all 4 at once with altivec. It would have to be
4 separate streams though, not 4 parts of a single stream.
> As to non-kernel applications, is there anything for GMP (the
> Gnu Multi-Precision library, an arbitrary-precision math library)
> on the Altivec? How aout the Cell?
I don't really know, sorry.
Paul.
^ 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