On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> This is the fourth submission of the new PS3 storage drivers:
> [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
> [2] ps3: Storage Driver Core
> [3] ps3: Storage device registration routines.
> [4] ps3: Disk Storage Dr
> > I was expecting a lower DMM performance but wasn't expecting such a
> > drain on kernel/network load.
>
> OK, to be clear: you seem to be saying that using the SLOB instead
> of the SLAB allocator results in such terrible memory fragmentation
> that network performance is degraded by large fac
Jens Axboe writes:
> I have no objections to the block bits, however I feel uneasy merging
> the full patchset unless patch #1 has been acked by the platform person.
I have the first 3 patches in my queue, so yes I've acked it. It's
probably easiest if the remaining 3 go through my queue once th
Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This patch allows multiple xilinxfb devices to be registered and used
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> cc: Andrei Konovalov <[EMAIL PROTECTED]>
> ---
Looks OK for me.
Thanks,
Andrei
> arch/ppc/syslib/virtex_
This patch add DMA sector to MPC8641HPCN board dts.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/powe
Hi, All,
These patches are DMA engine driver for Freescale MPC8xxx processor.
They implement the DMA engine API for MEM-2-MEM data DMA transfer
and extend the DMA engine API for IO_ADDR-2-MEM and IO_ADDR-2-IO_ADDR data
transfer.
Patches:
[PATCH 1/4] Add DMA sector to Documentation/powerpc/bootin
This patch adds DMA sector to Documentation/powerpc/booting-without-of.txt file.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 60 ++
1 files changed, 60 insertions(+), 0 delet
Add channel wait queue and transfer callback dma_xfer_callback().
If the DMA controller and driver support interrupt, when the
transfer is finished, it will wakeup the wait queue
and call the callback function of the channel.
Add dma_async_raw_xfer() to API and device_raw_xfer() to struct dma_devi
This driver adopts DMA engine API, which could be used for
MEM<-->MEM, IO_ADDR<-->MEM and IO_ADDR<-->IO_ADDR data transfer.
This driver support both Basic and Extended chain mode of Freescale
MPC8xxx DMA controller.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROT
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Manish Ahuja writes:
>
>> Repost to fix my email id.
>>
>> Fix to correct a possible infinite loop or an always true check when the
>> unsigned long counter "i" is used in
>> lmb_add_region() in the following for loop:
>>
>> for (i = rgn->cnt-1; i >=
Andreas Schwab writes:
> Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> > Manish Ahuja writes:
> >
> >> Repost to fix my email id.
> >>
> >> Fix to correct a possible infinite loop or an always true check when the
> >> unsigned long counter "i" is used in
> >> lmb_add_region() in the following f
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Andreas Schwab writes:
>> Paul Mackerras <[EMAIL PROTECTED]> writes:
>>
>> > Manish Ahuja writes:
>> >
>> >> Repost to fix my email id.
>> >>
>> >> Fix to correct a possible infinite loop or an always true check when the
>> >> unsigned long counter "
Andreas Schwab writes:
> >> ??? There is no rgn->cnt involved in the comparison.
> >
> > Look further down in lmb_add_region; there is a second for loop that
> > does
> >
> > for (i = rgn->cnt-1; i >= 0; i--)
>
> Which is exactly the one quoted above. I still don't see your point.
You're ri
On Tue, Jul 10 2007, Geert Uytterhoeven wrote:
> On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> > This is the fourth submission of the new PS3 storage drivers:
> > [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
> > [2] ps3: Storage Driver Core
> > [3] ps3: Storage d
On Tue, Jul 10 2007, Paul Mackerras wrote:
> Jens Axboe writes:
>
> > I have no objections to the block bits, however I feel uneasy merging
> > the full patchset unless patch #1 has been acked by the platform person.
>
> I have the first 3 patches in my queue, so yes I've acked it. It's
> probab
On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote:
> Kumar Gala wrote:
> >
> > On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >>>
> >>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> >>> easily.
>
Roland Dreier <[EMAIL PROTECTED]> wrote on 09.07.2007 23:35:31:
> Out of curiousity, does this mean that a GRH will be sent on all UD
> messages (for non-LL QPs)?
No - the bit instructs the hardware to fetch the GRH parts of the QP
context.
The GRH will only be used if the WQE says so.
Joachim
I just pushed the following patches to the for-2.6.23 branch on
powerpc.git. I intend to ask Linus to pull everything on the
for-2.6.23 branch shortly, unless I hear loud screams to the
contrary. :)
Paul.
Documentation/feature-removal-schedule.txt | 12 +
Documentation/powerpc/booting-witho
Wade Farnsworth writes:
> In order to use the RTC CMOS driver, each architecture must register a
> platform device for the RTC.
>
> This creates a function to register the platform device based on the RTC
> device node and verifies that the RTC port against the hard-coded value
> in asm/mc146818r
> +Sense and level information follows the Linux convention
> +(specified in include/linux/interrupt.h) and should be encoded
> +as follows:
> +
> + 1 = low to high edge sensitive type enabled
> + 2 = high to low edge sensitive type enabled
> + 4 = active high level sensitive type en
Hello.
Kumar Gala wrote:
> Move to using inline function variant of eieio instead of inline assmebly.
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@
>> I may be missing the obvious, but doesn't that defeat the purpose of
>> non-executable mappings?
>
> The hardware in question doesn't support non-executable mappings;
Not on a per-page basis, anyway.
> otherwise, it'd never have worked in the first place. Note that
> this is
> only allowed
> In older versions of glibc (through 2.3), the dynamic linker
> executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit
> 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period bef
Roland Dreier <[EMAIL PROTECTED]> wrote on 10.07.2007 00:11:42:
> thanks, I applied these for 2.6.23 and fixed a bunch of minor things
> that scripts/checkpatch.pl complained about (since I was in a mood to
> do mindless things).
Thanks! Both for the quick merge and for the fixes!
> In the futur
>> +Sense and level information follows the Linux convention
>> +(specified in include/linux/interrupt.h) and should be encoded
>> +as follows:
>> +
>> + 2 = high to low edge sensitive type enabled
>> + 8 = active low level sensitive type enabled
> ... but it is probably worthwhile c
> What decides if a QP is LL or not?
>
> - R.
Currently we use a high bit in the QP type, which is not how we want to
keep it permanently.
What would you suggest, add two additional LL QP types, or change something
more fundamental
in libibverbs and kernel ib core?
We think we can get along quit
> + [EMAIL PROTECTED]
> + compatible = "fsl,mpc8xxx-dma";
Please use a real name, not this "xxx" stuff.
> + reg = <21000 100>;
> + ranges = <0 21000 1000>;
These overlap, that can't be right; it is just begging for
trouble.
> + [EMAIL PROTECTED]
"dma-controller" btw. And a space before the "{" (here and
elsewhere) :-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
> + k) DMA
> +
> + This sector define DMA for dma-engine driver of Freescale
It's called a "device node" or "node", not a "sector".
> +- compatible : Should be "fsl,mpc8xxx-dma"
Should _include_, not should _be_. And none of this xxx
business, of course.
> +- extended : Set the DMA
> This scales with the number of processors since there is one
> decrementer per core (is it per thread on SMT chips?
> I don't know).
One per core.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linux
> -Original Message-
> From: Segher Boessenkool [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 10, 2007 8:21 AM
> To: Grant Likely
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH v2][POWERPC] document ipic level/sense info
>
> >> +Sense and
On Jul 10, 2007, at 8:21 AM, Segher Boessenkool wrote:
>>> +Sense and level information follows the Linux convention
>>> +(specified in include/linux/interrupt.h) and should be encoded
>>> +as follows:
>>> +
>>> + 2 = high to low edge sensitive type enabled
>>> + 8 = active low leve
Adds the H_ILLAN_ATTRIBUTES hcall
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/include/asm-powerpc/hvcall.h |1 +
1 file changed, 1 insertion(+)
diff -puN include/asm-powerpc/hvcall.h~powerpc_illan_attrs
include/asm-powerpc/hvcall.h
--- linux-2.6/include/asm-powerpc
On Jul 10, 2007, at 1:34 AM, Zhang Wei wrote:
> If the PCI-Ex hose link training is failed, the kernel will halt at
> the
> PCI scan process on MPC8641HPCN board.
>
> This patch will remove and free the hose from PCI host list if the
> PCI hose link training is failed.
>
> Signed-off-by: Zhang
document level/sense encoding info for IPIC
interrupt controllers
Signed-off-by: Stuart Yoder <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.
On 7/10/07, Andrei Konovalov <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > This patch allows multiple xilinxfb devices to be registered and used
> >
> > Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> > cc: Andrei Konovalov <[EMAIL PROTECTED]>
On 7/10/07, Stuart Yoder <[EMAIL PROTECTED]> wrote:
> document level/sense encoding info for IPIC
> interrupt controllers
>
> Signed-off-by: Stuart Yoder <[EMAIL PROTECTED]>
> ---
> + 2 = high to low edge sense type enabled
> + 8 = active low level sense type enabled
> +
> +Note: othe
All of the platforms except PPC64 share a common mm_context_t definition.
Defining it in mmu.h avoids duplicating it in the platform specific mmu
header files.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
include/asm-powerpc/mmu-44x.h |5 -
include/asm-powerpc/mmu-8xx.h
This series of patches do:
(1) unify the PCI/PCI express support
for 83xx/85xx/86xx.
(2) Add basic PCI Express support for mpc8548 Rev 2.0
board.
(3) Add basic PCI support for mpc8568mds board.
The patches have been tested on 8548 rev2.0 with Arcadia 3.1
board, mpc8568mds board and 8641HPCN
From: Roy Zang <[EMAIL PROTECTED]>
Move
arch/powerpc/platforms/86xx/pci.c -> arch/powerpc/sysdev/fsl_pci.c
arch/powerpc/sysdev/fsl_pcie.h -> arch/powerpc/sysdev/fsl_pci.h
as the base to unify 83xx/85xx/86xx pci and pcie.
Add CONFIG_FSL_PCI to build fsl_pci.c for Freescale pci and pcie option.
The
From: Roy Zang <[EMAIL PROTECTED]>
Rewrite Freescale pci/pcie routing for 83xx/85xx/86xx pci/pcie
controller.
The routing are common for 83xx/85xx/86xx pci/pcie host.
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_pci.c | 244 ++---
From: Roy Zang <[EMAIL PROTECTED]>
Add 8548 CDS PCI express controller node and PCI-X device node.
The current dts file is suitable for 8548 Rev 2.0 board with
Arcadia 3.1.
This kind of board combination is the most popular.
Indentify pci, pcie host by compatible property "fsl,mpc85xx-pci"
and "
From: Roy Zang <[EMAIL PROTECTED]>
User Freescale pci/pcie common routing for 83xx/85xx/86xx
boards.
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/platforms/83xx/Kconfig|4 +
arch/powerpc/platforms/83xx/mpc8313_rdb.
From: Roy Zang <[EMAIL PROTECTED]>
Update the 83xx/85xx/86xx boards device tree.
Indentify pci, pcie host by compatible property
"fsl,mpc83xx-pci","83xx"
"fsl,mpc85xx-pci","85xx"
"fsl,mpc86xx-pci","86xx"
and
"fsl, mpc85xx-pciex","85xx"
"fsl, mpc86xx-pciex","86xx"
Signed-off-by: Roy Zang <[EMAIL
From: Roy Zang <[EMAIL PROTECTED]>
Add basic PCI node for mpc8568mds board.
Signed-off-by: Haiying Wang <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 29 +
1 fi
On Tue, Jul 10, 2007 at 04:01:19PM +0200, Segher Boessenkool wrote:
> > +- compatible : Should be "fsl,mpc8xxx-dma"
>
> Should _include_, not should _be_. And none of this xxx
> business, of course.
Especially since the 85xx/86xx version is not 100% compatible with the
83xx version. How abo
On Tuesday 10 July 2007, Josh Boyer wrote:
> +#ifdef CONFIG_PPC64
> +typedef unsigned long mm_context_id_t;
> +
> +typedef struct {
> + mm_context_id_t id;
> + u16 user_psize; /* page size index */
> +
> +#ifdef CONFIG_PPC_MM_SLICES
> + u64 low_slices_psize; /* SLB page
On Tue, 10 Jul 2007 17:45:11 +0800 Zhang Wei wrote:
> Add channel wait queue and transfer callback dma_xfer_callback().
> If the DMA controller and driver support interrupt, when the
> transfer is finished, it will wakeup the wait queue
> and call the callback function of the channel.
>
> Add dma
On Tue, 2007-07-10 at 18:36 +0200, Arnd Bergmann wrote:
> On Tuesday 10 July 2007, Josh Boyer wrote:
> > +#ifdef CONFIG_PPC64
> > +typedef unsigned long mm_context_id_t;
> > +
> > +typedef struct {
> > + mm_context_id_t id;
> > + u16 user_psize; /* page size index */
> > +
> > +
In order to use the RTC CMOS driver, each architecture must register a
platform device for the RTC.
This creates a function to register the platform device based on the RTC
device node and verifies that the RTC port against the hard-coded value
in asm/mc146818rtc.h.
Signed-off-by: Wade Farnsworth
On Tuesday 10 July 2007, Josh Boyer wrote:
> > + u16 user_psize; /* page size index */
> > +
> > +#ifdef CONFIG_PPC64
>
> This needs to be moved up to encompass the u16 user_psize member as
> well, yes?
>
Yes, of course. my bad.
Arnd <><
___
Jan-Bernd Themann wrote:
> This patch introduces a capability flag that is used by the DLPAR userspace
> tool to check which DLPAR features are supported by the eHEA driver.
>
> Missing goto has been included.
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
applied
___
Jan-Bernd Themann wrote:
> This patch enables the receive side processing to aggregate TCP packets within
> the HEA device driver. It analyses the packets already received after an
> interrupt arrived and forwards these as chains of SKBs for the same TCP
> connection with modified header field. We
Vitaly Bordug wrote:
> device_bind_driver() error code returning has been fixed.
> release() function has been written, so that to free resources
> in correct way; the release path is now clean.
>
> Before the rework, it used to cause
> Device '[EMAIL PROTECTED]:1' does not have a release() func
All of the platforms except PPC64 share a common mm_context_t definition.
Defining it in mmu.h avoids duplicating it in the platform specific mmu
header files. We further consolidate it by having the PPC32 definition
share the mm_context_id_t type for the id member.
Signed-off-by: Josh Boyer <[EM
On Tue, 2007-07-10 at 22:38 +1000, Paul Mackerras wrote:
> I just pushed the following patches to the for-2.6.23 branch on
> powerpc.git. I intend to ask Linus to pull everything on the
> for-2.6.23 branch shortly, unless I hear loud screams to the
> contrary. :)
Can we get Ben's new emac driver
hello,
I am trying to implement hugetlbfs on the IBM Bluegene/L IO node
(ppc440) and I have a big problem as well as a few questions to ask
the group. I patched a 2.6.21.6 linux kernel (manually) with Edi
Shmueli's hugetlbfs implementation (found here:
http://patchwork.ozlabs.org/linuxppc/patch?id=
Paul Mackerras wrote:
> Andreas Schwab writes:
>
>
??? There is no rgn->cnt involved in the comparison.
>>> Look further down in lmb_add_region; there is a second for loop that
>>> does
>>>
>>> for (i = rgn->cnt-1; i >= 0; i--)
>>>
>> Which is exactly the one quoted
On 7/10/07, Zhang Wei <[EMAIL PROTECTED]> wrote:
> Add channel wait queue and transfer callback dma_xfer_callback().
> If the DMA controller and driver support interrupt, when the
> transfer is finished, it will wakeup the wait queue
> and call the callback function of the channel.
>
> Add dma_asyn
On Sun, Jul 08, 2007 at 03:15:41PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > on the argument that drivers/ide/ is going away soon. Most
> > current distros have already moved over to using libata
> > exclusively.
>
> The in-kernel default for PATA systems is still IDE subsystem.
In part beca
The patch has not been included and there have been no comments so
I'm resending.
This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
The new name is ppc64/power5++ and is used so that the performance
counters can be set up correctly.
Signed-off-by: Mike Wolf <[EMAIL PROTECTED]>
+Sense and level information follows the Linux convention
+(specified in include/linux/interrupt.h) and should be encoded
+as follows:
+
+ 2 = high to low edge sensitive type enabled
+ 8 = active low level sensitive type enabled
>>
>>> ... but it is proba
>>> ... but it is probably worthwhile commentting that sense types 1 & 4
>>> are not supported; just to fill in the obvious gaps. :-)
>>
>> Same for sense types 0, 3, 5, 6, ...
>>
>> Just name the sense types 0 and 1, similar to what all other
>> OF interrupt controller bindings do.
>
> I'm not re
> The patch has not been included and there have been no comments so
> I'm resending.
>
> This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
> The new name is ppc64/power5++ and is used so that the performance
> counters can be set up correctly.
Does it make more sense to call
Hi Everyone,
Hoang-Nam Nguyen reported a bug in idr_get_new_above()
which occurred with a starting id value like 0x3ffc.
His test module easily reproduced the problem. Thanks.
The test revealed the following bugs:
1. Relying on shift operations which have undefined results
e.g.: 1 << n
Michael Neuling wrote:
>> The patch has not been included and there have been no comments so
>> I'm resending.
>>
>> This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
>> The new name is ppc64/power5++ and is used so that the performance
>> counters can be set up correctly.
>>
> pci1: [EMAIL PROTECTED] {
> interrupt-map-mask = <1f800 0 0 7>;
Set the mask to <1800 0 0 7>, and you need only 16
entries to encode the swizzle. Except...
> + /* bus 1 , idsel 0x2 Tsi310 bridge secondary */
...interrupts on bus
> Indentify pci, pcie host by compatible property
> "fsl,mpc83xx-pci","83xx"
> "fsl,mpc85xx-pci","85xx"
> "fsl,mpc86xx-pci","86xx"
> and
> "fsl, mpc85xx-pciex","85xx"
> "fsl, mpc86xx-pciex","86xx"
This can't ever work -- if you see "compatible" = "85xx",
what is it? PCI or PCIe? Or something els
> >
> > Does it make more sense to call this "ppc64/power5+rev3"?
> >
> This is a change to support new counter setup for oprofile. It may be the
> same if there is a revision 4 or 5 etc. So since the internal name was ++
> I followed that convention.
I'm not too fussed, but if rev 4 comes
On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
> > >
> > > Does it make more sense to call this "ppc64/power5+rev3"?
> > >
> > This is a change to support new counter setup for oprofile. It may be the
> > same if there is a revision 4 or 5 etc. So since the internal name was ++
>
Will Schmidt wrote:
> On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
>
Does it make more sense to call this "ppc64/power5+rev3"?
>>>
>>>This is a change to support new counter setup for oprofile. It may be the
>>>same if there is a revision 4 or 5 etc. So since the inter
[ added Kou back to cc: ]
On Tuesday 10 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
> > Move to using inline function variant of eieio instead of inline assmebly.
>
> > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
applied
Please use host driver name ("scc_pata" in this c
This series creates a 32 bit zImage wrapper for a 32 or 64 bit PowerPC
Linux kernel. This allows you to kexec a zImage with its compressed
vmlinux instead of the uncompressed vmlinux elf. The elf is also
packaged as a 64 bit elf for use by kexec-tools for 64 bit kernels.
This series also adds c
Some platforms have a boot agent that can create or modify properties in
the device-tree and load images into memory. Provide a helper to set
loader_info used by prep_initrd().
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Moved to devtree.c as suggested.
define UNIT_MAX hardcoded as req
Record the number of header bytes skipped in the total bytes read field.
This is needed for the initramfs parsing code to find the end of the zip file.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Index: work.git/arch/powerpc/boot/gunzip_util.c
=
Call gunzip_partial to calculate the remaining length and copy the
data to the user buffer. This makes it shorter and reduces
duplication.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Index: work.git/arch/powerpc/boot/gunzip_util.c
=
Support code to move cpus around, both a spin loop and c code to
move the cpus before uncompressing and copying the kernel to 0.
The low level code is designed to be included in a crt0 or other
assembly file because it may need to be at a fixed location or there
may be other entry point requireme
Add a set of library routines to manage gross memory allocations.
This code uses an array in bss to store upto 32 entrys with merging
representing a range of memory below rmo_end (aka end of real mode
memory at 0).
To use this code, a platform would set rmo_end, call occupy_memory,
then then call
Add code to check if the processor is in 64 or 32 bit mode using
only instructions from the 32 bit subset. If the processor is in
64 bit mode, switch to 32 bit mode by clearing MSR[SF].
Also add a 64 bit procedure descriptor to use as a elf64 entry
point.
Signed-off-by: Milton Miller <[EMAIL PRO
This code creates a 32 bit zImage wrapper for a 32 or 64 bit PowerPC
Linux kernel. This allows you to kexec a zImage with its compressed
vmlinux instead of the uncompressed vmlinux elf. The elf is also
packaged as a 64 bit elf for use by kexec-tools for 64 bit kernels.
Limitations:
The memory
kexec-tools still produces a version 2 device tree, while the
libraries in the wrapper only support version 16 and later.
Add a routine to convert a v2 flat device tree to a v16 one inplace
by inserting OF_DT_NOP and chomping full path. Make space for new
headers by moving and then chomping the O
This code provides a console write that calls put-term-char.
To avoid PIC relocation of the absolute rtas addresses, hide the
actual call to rtas in assembly and declare all variables as int.
An instantiated rtas will be protected by a reserved range in the
device tree, so no explicit call to add
Add a library to search through a cpio or initramfs to a specified
path contained in a cpio.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Status: tested and working.
This file is designed to also be usable in a stand alone user space
application.
Index: work.git/arch/powerpc/boot/cpio
Allow the boot wrapper to obtain the vmlinux elf from an external
platform supplied location instead of embedding it at link time.
When used with the cpio library, the kernel can be stored as a file
an file in the initramfs, allowing the same (compressed) copy of
the vmlinux elf to be used for bot
Teach the kexec platform to find the vmlinux from the initramfs.
The implementation searches the initramfs for a file specified
by the boot-file property in chosen.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Status: working.
Index: work.git/arch/powerpc/boot/kexec.c
=
Allow the boot wrapper code to be linked without an attached vmlinux.
Rather than invent a new syntax to invoke the wrapper, attach the
stripped version of empty.o, which produces the same result.
This new intermediary is called zBoot.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Initia
The kexec code is doing strange contortions with dtops.finalize and
platform_ops.vmlinux_alloc to manage the slave cpus. Add a hook
with the needed information.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Index: work.git/arch/powerpc/boot/kexec.c
An example using the marshalling code that can be entered by sreset.
By linking the marshalling code is at 0 and differentiating a cpu
id from a device tree, it also works for kexec.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
For reference only, not intended to be merged.
Index: work.
> + /* Check if the processor is running in 32 bit mode, using
> + * only 32 bit instructions which should be safe on 32 and
> + * 64 bit processors.
> + *
> + * Subtract the bottom 32 bits of MSR from the full value
> + * recording the result. Since MSR[SF] is in the
> Allow the boot wrapper to obtain the vmlinux elf from an external
> platform supplied location instead of embedding it at link time.
>
> When used with the cpio library, the kernel can be stored as a file
> an file in the initramfs, allowing the same (compressed) copy of
> the vmlinux elf to be u
On Tue, 10 Jul 2007 11:52:59 +0800, Albert Lee wrote:
> >>Recently the PLL input clock of pata_pdc2027x is sometimes detected
> >>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
> >>It seems sometimes the mdelay() function is not as precise as it
> >>used to be. Per Alan's advice, HT
> The memory node off the root with a name starting with "memory" must
> contain enough free memory (not in the reserved ranges) in the first
> reg range to uncompress the the kernel with padding.
There can be many nodes called "/memory". You probably
want to use the node pointed to by /chosen/me
Manish Ahuja writes:
> I presume the patch is good then. Do I need to change anything ?
I guess not. It will cause a warning on the first for loop if anyone
tries to compile with -Wextra or -Wsign-compare, but it would be only
one of lots of warnings in that case (and in fact comparing signed
wi
Josh Boyer writes:
> All of the platforms except PPC64 share a common mm_context_t definition.
> Defining it in mmu.h avoids duplicating it in the platform specific mmu
> header files. We further consolidate it by having the PPC32 definition
> share the mm_context_id_t type for the id member.
Un
Segher Boessenkool writes:
> > This scales with the number of processors since there is one
> > decrementer per core (is it per thread on SMT chips?
> > I don't know).
>
> One per core.
No, each thread has its own decrementer, but the timebase is shared.
Paul.
__
Segher Boessenkool writes:
> Yeah. Giving the warning is a good thing though.
No, it isn't; it's just noise, if we're not ever going to do anything
to prevent the behaviour - and we can't.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
ht
>> Yeah. Giving the warning is a good thing though.
>
> No, it isn't; it's just noise, if we're not ever going to do anything
> to prevent the behaviour - and we can't.
The same userland code will not run correctly on PPC64 or BookE
systems. Is that not a reason to warn?
Segher
__
>>> This scales with the number of processors since there is one
>>> decrementer per core (is it per thread on SMT chips?
>>> I don't know).
>>
>> One per core.
>
> No, each thread has its own decrementer, but the timebase is shared.
Argh, of course you're right, I'm reading the wrong ISA
version
>> In older versions of glibc (through 2.3), the dynamic linker
>> executes a
>> small amount of code from the data segment, which is not marked as
>> executable. A recent change (commit
>> 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
>> stops this from working; there should be a deprecation peri
Segher Boessenkool writes:
> >> Yeah. Giving the warning is a good thing though.
> >
> > No, it isn't; it's just noise, if we're not ever going to do anything
> > to prevent the behaviour - and we can't.
>
> The same userland code will not run correctly on PPC64 or BookE
> systems. Is that not
1 - 100 of 108 matches
Mail list logo
