* Help for USB host driver for MPC8xx
From: wei.li4 @ 2006-08-02 14:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Dose anyone use USB host drivers for MPC875 with Linux 2.4.25? I just
found these notes from http://www.heeltoe.com/software/usb/usb.html,
but I have no idea about how to use it, any advice? Thanks.
Wei
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Kumar Gala @ 2006-08-02 13:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <528646bc0608012020l11690cf7wbb7d93e6ba6eae90@mail.gmail.com>
On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
> On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
>> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
>>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
>>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
>>>>>
>>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
>>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
>>>>
>>>> I believe in his latest patches he removed this part. The device
>>>> trees
>>>> were not included at all and he left this point open for
>>>> discussion.
>>>
>>> That's correct.
>>>
>>> TBH, I think its wrong to keep them in the kernel source at all--
>>> yes,
>>> the same argument could be made for arch/powerpc/boot but that's
>>> been
>>> settled.
>>
>> Sorry, I have to disagree. We're talking about device tree _source_
>> files here. I believe they should be included in the kernel source.
>> Where that is, I don't have a particularly strong argument but they
>> should be included.
>
> I have to second that opinion. The device tree is absolutely integral
> with the rest of the code/drivers needed to support a board. I say
> there are stronger arguments for keeping the dts files in the kernel
> source than there are for the boot wrapper.
>
> powerpc/boot/dts makes a lot of sense to me.
I like this location and agree that having them in tree makes sense.
And putting them under boot isolates them from the kernel proper.
The reason I see to having them in tree is to ensure proper version
compatibility. This way there is no concern about which .dts version
will work with which kernel. In the future we can always pull them
out when things are more stable.
- kumar
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Kumar Gala @ 2006-08-02 13:32 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
On Aug 2, 2006, at 3:25 AM, Adrian Cox wrote:
> Is anybody else having problems with 32-bit SMP support in arch/
> powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the
> kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second
> CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
There are a few patches to prom.c that may help. I know I've run
into this on other 32-bit systems booting from u-boot. These patches
resolved my issue.
* [PATCH] powerpc: Auto reserve of device tree blob
* [POWERPC] Prevent duplicate lmb reservations for Device...
- kumar
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Arnd Bergmann @ 2006-08-02 12:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <17616.12251.339657.215571@cargo.ozlabs.ibm.com>
On Wednesday 02 August 2006 06:53, Paul Mackerras wrote:
> > +#ifdef __powerpc64__
> > +typedef unsigned long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0u=
64;
> > +#else
> > +typedef unsigned long long=A0=A0=A0u64;
> > +#endif
>=20
> This is potentially confusing, because the __powerpc64__ relates to
> the boot wrapper not the kernel, and we don't build a 64-bit boot
> wrapper on any platform (not yet anyway). =A0Maybe this needs a comment.
>=20
Moreover, even if we ever build this on __powerpc64__, the=20
typedef unsigned long long u64 would still do the right thing.
It only ever becomes a problem when mixing with u64 the c99 uint64_t,
which is defined the other way.
Arnd <><
^ permalink raw reply
* Re: cool article
From: Ameet Patil @ 2006-08-02 10:15 UTC (permalink / raw)
To: edb; +Cc: linuxppc-embedded
In-Reply-To: <44CF89B5.7080906@datadesigncorp.net>
> Did you happen to get an Ethernet mac going on the virtex2 or
> virtex4 with the 2.6 kernel?
Nope! :-(
Rumour has it that Montavista is soon going to release the source for
2.6 kernel to run on Xilinx platforms.
-Ameet
Edward Bockhoefer wrote:
> Hello Ameet,
> I too am working on this type of project. I am trying to get the xilinx
> obp 10/100 mac driver into the 2.6.17.6 kernel. Unfortantly, I think I
> need some of the montavista sources not generated by the xilinx
> software, which only generates driver code for the 2.4 montavista
> kernel. Did you happen to get an Ethernet mac going on the virtex2 or
> virtex4 with the 2.6 kernel?
>
> Ed
>
> Ameet Patil wrote:
>
>> Thanks Ed! I did get a root fs up and running NOT using JFFS2 though.
>> I used ext2.
>>
>> cheers,
>> -Ameet
>>
>> Edward Bockhoefer wrote:
>>
>>> I found your post about the Virtex II part one at
>>> http://www.linux.get2knowmore.com. Thanks for the info. Did you
>>> happen to get a root fs up and running using jffs2?
>>>
>>> Best Regards,
>>> Ed
>>>
>>>
>>
>
>
>
^ permalink raw reply
* RE: SMP in 32-bit arch/powerpc
From: Zhang Wei-r63237 @ 2006-08-02 9:27 UTC (permalink / raw)
To: Adrian Cox, linuxppc-dev
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
Do you have more detailed descriptions? Our MPC8641D(dual-7448 core CPU)
board works well.
Best Regards,
Zhang Wei=20
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Adrian Cox
> Sent: Wednesday, August 02, 2006 4:26 PM
> To: linuxppc-dev@ozlabs.org
> Subject: SMP in 32-bit arch/powerpc
>=20
> Is anybody else having problems with 32-bit SMP support in=20
> arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>=20
> I'm currently bringing up a dual-7448 board, and when I build=20
> the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the=20
> second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
>=20
> --=20
> Adrian Cox <adrian@humboldt.co.uk>
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: lockup during powersave on G3
From: Michael Ellerman @ 2006-08-02 9:21 UTC (permalink / raw)
To: marvin; +Cc: linuxppc-dev
In-Reply-To: <200608020747.50765.marvin24@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Wed, 2006-08-02 at 07:47 +0200, marvin wrote:
> hi,
>
> since kernel 2.6.18-rc1 my b/w G3 mac locks up every time it goes into
> powersave mode. Before trying to bisect, is there a candidate I can try to
> revert?
By "since" do you mean 2.6.18-rc1 worked and it's broken since then, or
that something earlier worked and it's broken starting from 2.6.18-rc1?
Ben's new irq stuff might be a candidate, that was a pretty big change.
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: SMP in 32-bit arch/powerpc
From: Michael Ellerman @ 2006-08-02 9:08 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On Wed, 2006-08-02 at 09:25 +0100, Adrian Cox wrote:
> Is anybody else having problems with 32-bit SMP support in arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
Seems to be working OK here:
fuego:~# uname -a
Linux fuego 2.6.17 #1 SMP Mon Jul 3 12:10:43 EST 2006 ppc GNU/Linux
fuego:~# cat /proc/cpuinfo
processor : 0
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 1
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 2
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 3
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
total bogomips : 330.75
timebase : 41500582
platform : CHRP
machine : CHRP IBM,7025-F50
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][2/2] RTAS MSI
From: Michael Ellerman @ 2006-08-02 9:04 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154379714.29826.396.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
On Mon, 2006-07-31 at 16:01 -0500, Jake Moilanen wrote:
> Here's version 3 which addresses all of Michael's comments.
Sorry, more questions :)
> Index: 2.6-msi/drivers/pci/msi-rtas.c
> ===================================================================
> --- /dev/null
> +++ 2.6-msi/drivers/pci/msi-rtas.c
> @@ -0,0 +1,99 @@
> +/*
> + * Jake Moilanen <moilanen@austin.ibm.com>
> + * Copyright (C) 2006 IBM
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/irq.h>
> +#include <asm/rtas.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +
> +int rtas_enable_msi(struct pci_dev* pdev)
> +{
> + int seq_num = 1;
> + int i;
> + int rc;
> + int query_token = rtas_token("ibm,query-interrupt-source-number");
> + int ret[2];
> + int n_intr;
> + int last_virq = NO_IRQ;
> + int virq;
> + unsigned int addr;
> + unsigned long buid;
> + struct device_node * dn;
> +
> + dn = pci_device_to_OF_node(pdev);
> +
> + if (!of_find_property(dn, "ibm,req#msi", NULL))
> + return -ENOENT;
> +
> + buid = get_phb_buid(dn->parent);
> + addr = (pdev->bus->number << 16) | (pdev->devfn << 8);
> +
> + do {
> + rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
> + buid >> 32, buid & 0xffffffff,
> + 0, 0, seq_num);
> +
> + seq_num = ret[1];
> + } while (rtas_busy_delay(rc));
> +
> + if (rc) {
> + printk(KERN_WARNING "error[%d]: getting the number of "
> + "MSI interrupts for %s\n", rc, dn->name);
> + return -EIO;
> + }
> +
> + /* Return if there's no MSI interrupts */
> + if (!ret[0])
> + return -ENOENT;
> +
> + n_intr = ret[0];
> +
> + for (i = 0; i < n_intr; i++) {
> + do {
> + rc = rtas_call(query_token, 4, 3, ret, addr,
> + buid >> 32, buid & 0xffffffff, i);
> + } while (rtas_busy_delay(rc));
> +
> + if (!rc) {
> + virq = irq_create_mapping(irq_find_host(dn), ret[0],
> + ret[1] ? IRQ_TYPE_EDGE_RISING :
> + IRQ_TYPE_LEVEL_LOW);
I'm only just starting to get benh's new irq code, but I think
irq_find_host(dn) isn't doing what we want here. It's probably harmless,
but AFAICT irq_find_host() is only meant to be called when you have the
node of the irq controller, not for an arbitrary dn. The doco's a bit
ambiguous:
* irq_find_host - Locates a host for a given device node
* @node: device-tree node of the interrupt controller
But looking at the implementation, it doesn't do a search up the tree or
anything, it just checks node against each host.
Also, since's benh's latest patch went in we'll have to split this into
two calls, I think we want:
virq = irq_create_mapping(NULL ???, ret[0]);
set_irq_type(virq, ret[1] ? IRQ_TYPE_EDGE_RISING : IRQ_TYPE_LEVEL_LOW);
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
* SMP in 32-bit arch/powerpc
From: Adrian Cox @ 2006-08-02 8:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Is anybody else having problems with 32-bit SMP support in arch/powerpc?
I'm using 2.6.17 as my current base, because I've not yet merged the
latest mpic changes.
I'm currently bringing up a dual-7448 board, and when I build the kernel
with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
strange thing is, this still happens when I don't start the second CPU.
Kernels built without CONFIG_SMP run flawlessly on the same hardware.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* 82xx PCI setup ioremapping twice
From: Kalle Pokki @ 2006-08-02 7:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
In pq2_find_bridges(), there is a call to setup_m8260_indirect_pci(),
which ioremaps the configuration address and data registers. The call
uses the cpm2_immr pointer, which however is already ioremapped by
cpm2_reset(). ioremapping these addresses twice seems to always crash
my board, and I need to e.g.
Index: linux-2.6.15.4/arch/ppc/syslib/m82xx_pci.c
===================================================================
--- linux-2.6.15.4.orig/arch/ppc/syslib/m82xx_pci.c 2006-08-02
09:45:54.000000000 +0300
+++ linux-2.6.15.4/arch/ppc/syslib/m82xx_pci.c 2006-08-02
09:46:32.000000000 +0300
@@ -324,7 +324,7 @@
hose->set_cfg_type = 1;
#endif
- setup_m8260_indirect_pci(hose,
+ setup_indirect_pci_nomap(hose,
(unsigned long)&cpm2_immr->im_pci.pci_cfg_addr,
(unsigned
long)&cpm2_immr->im_pci.pci_cfg_data);
or use the physical addresses in the original function call.
Should ioremap() code check for these double mappings? There seems to
be some attempts to do that. I remember the PCI initialisation wasn't
a problem some time before with an earlier kernel version, a different
8248 board, and internal memory at 0xf0000000.
My internal memory is at physical address 0xff000000.
Linux kernel version is 2.6.15.4.
The board is a custom 8247.
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-08-02 6:15 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <17616.12251.339657.215571@cargo.ozlabs.ibm.com>
I wrote:
> The ops structure seems like a reasonable concept, but I question
> whether we need to have platform_ops separate from fw_ops, since the
> firmware is essentially part of the implementation of the platform.
> Also I don't see why we need to do a double indirection to get to each
> ops function.
Thinking about this a bit more, why do we need the indirect function
calls at all? Do we ever want to be able to choose (e.g.) one of
several possible console implementations at runtime? Don't we know at
compile time which one we will be using, and thus can't we use the
linker to make the necessary linkages?
Regards,
Paul.
^ permalink raw reply
* lockup during powersave on G3
From: marvin @ 2006-08-02 5:47 UTC (permalink / raw)
To: linuxppc-dev
hi,
since kernel 2.6.18-rc1 my b/w G3 mac locks up every time it goes into
powersave mode. Before trying to bisect, is there a candidate I can try to
revert?
marc
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-08-02 5:35 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154474791.3987.7.camel@localhost.localdomain>
> I'm not sure what disable really needs to do, but I think drivers
> might
> expect it to set dev->irq back to the LSI value, even if we don't free
> anything internally. Not sure.
Yes, that's required by the MSI API.
Segher
^ permalink raw reply
* Re: [PATCH] turn on tigon3 support in maple_defconfig
From: Segher Boessenkool @ 2006-08-02 5:30 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060801194411.GA22933@kvasir.watson.ibm.com>
> I think that most people who use maple_defconfig are doing so for a
> JS21,
> so it might make sense to turn Tigon3 support on by default.
Also needed on JS20.
> Built and booted on a JS21.
>
> Signed-off-by: Amos Waterland <apw@us.ibm.com>
ACK.
Segher
^ permalink raw reply
* linux USB host problem
From: robinpv @ 2006-08-02 5:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am using linux 2.6.16.1 for MPC5200 based platorm. It has PCI based USB Host (SM501 chip)
I am facing problem in the USB host interrupts. When i plug in the USB i get the
below message.
new full speed USB device using vgxfb and address 2.
vgxfb 0000:00:10.0: Unlink after no-IRQ? Controller is probably using the
wrong IRQ.
the capture of /pci/interrupts is
CPU0
1: 0 MPC52xx Level ohci_hcd:usb1
7: 751 MPC52xx Level eth0
40: 7899 MPC52xx Level mpc52xx_psc_uart
BAD: 0
The device address is assigned but after that interrupt is not coming.
After that if i unplug and plugin there is no notification.
the sm501 chip in which USB host is there, is connected on PCI bus.
The PCI mapping is as follows
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
{PIRQA, PIRQA, PIRQA, PIRQA}, /* SM501 */
{PIRQD, PIRQD, PIRQD, PIRQD}, /* IDE */
{PIRQC, PIRQC, PIRQC, PIRQC}, /* Ethernet */
{PIRQB, PIRQB, PIRQB, PIRQB}, /* Bridge */
};
const long min_idsel = 16, max_idsel = 18, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
I tried with acpi=off, but in vain.
Can some give inputs on this how to proceed.
Thanks & Regards,
Robin
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-08-02 4:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719230014.GB3887@mag.az.mvista.com>
Mark A. Greer writes:
> Abstract the operations used in the bootwrapper. The operations
> have been divided up into platform ops (platform_ops), firware ops
> (fw_ops), device tree ops (dt_ops), and console ops (console_ops).
Overall the approach looks good.
The ops structure seems like a reasonable concept, but I question
whether we need to have platform_ops separate from fw_ops, since the
firmware is essentially part of the implementation of the platform.
Also I don't see why we need to do a double indirection to get to each
ops function.
Also, we will probably want to create some directory structure under
arch/powerpc/boot in the longer term.
> +#ifdef __powerpc64__
> +typedef unsigned long u64;
> +#else
> +typedef unsigned long long u64;
> +#endif
This is potentially confusing, because the __powerpc64__ relates to
the boot wrapper not the kernel, and we don't build a 64-bit boot
wrapper on any platform (not yet anyway). Maybe this needs a comment.
Paul.
^ permalink raw reply
* Re: [PATCH] fix PMU initialization on pseries lpar
From: Michael Ellerman @ 2006-08-02 4:29 UTC (permalink / raw)
To: Sonny Rao; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060802042009.GA15567@kevlar.burdell.org>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
On Wed, 2006-08-02 at 00:20 -0400, Sonny Rao wrote:
> We should not be calling power4_enable_pmcs() in
> pseries_lpar_enable_pmcs(); just doing the hypercall is sufficient.
> Prior to 2.6.15 we did not call power4_enable_pmcs() for an lpar.
>
> power4_enable_pmcs() tries to read the hid0 register which is no
> longer legal for an lpar in newer Power processors.
Argh, how did I miss that. Mea culpa.
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] Fix loop logic in irq_alloc_virt()
From: Michael Ellerman @ 2006-08-02 4:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060802004852.C66FB67B7F@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Wed, 2006-08-02 at 10:48 +1000, Michael Ellerman wrote:
> There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
> if it can't find a slot it might look past the end of the irq_map.
>
> I think this is a fix. No one in the kernel actually calls this with
> count > 1, so it's not critical.
> Index: to-merge/arch/powerpc/kernel/irq.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/irq.c
> +++ to-merge/arch/powerpc/kernel/irq.c
> @@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
> /* Look for count consecutive numbers in the allocatable
> * (non-legacy) space
> */
> - for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
> - for (j = i; j < (i + count); j++)
> - if (irq_map[j].host != NULL) {
> - i = j + 1;
> - continue;
> - }
> - found = i;
> - break;
To be clear: the bug is that the continue affects the inner for loop,
not the outer one, so i becomes j + 1 and then we continue the inner
loop without checking if i is still <= limit.
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
* [PATCH] fix PMU initialization on pseries lpar
From: Sonny Rao @ 2006-08-02 4:20 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
We should not be calling power4_enable_pmcs() in
pseries_lpar_enable_pmcs(); just doing the hypercall is sufficient.
Prior to 2.6.15 we did not call power4_enable_pmcs() for an lpar.
power4_enable_pmcs() tries to read the hid0 register which is no
longer legal for an lpar in newer Power processors.
--- a/arch/powerpc/platforms/pseries/setup.c 2006-04-23 01:45:09.000000000 -0500
+++ b/arch/powerpc/platforms/pseries/setup.c~pmcfix 2006-08-01 23:12:39.000000000 -0500
@@ -182,8 +182,6 @@ static void pseries_lpar_enable_pmcs(voi
{
unsigned long set, reset;
- power4_enable_pmcs();
-
set = 1UL << 63;
reset = 0;
plpar_hcall_norets(H_PERFMON, set, reset);
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Grant Likely @ 2006-08-02 4:17 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
On 7/25/06, Clint Thomas <cthomas@soneticom.com> wrote:
>
>
> Hey guys,
>
> I have gone through the Linuxppc embedded and dev lists for information
> related to what I am trying to do, but was unable to find exactly what i'm
> looking for.
>
> Basically, the system I want linux running on does not require the
> initialization of hardware that U-boot provides, or at least it does not
> need it to boot the linux kernel. I want to load an uncompressed linux
> kernel into memory and start the execution of the kernel, without using any
> kind of bootloader. Is this possible? Or does linux need some kind of
> firmware or other software to tell it to start executing? Thanks for any
> info you might have.
Loading a kernel into memory and starting execution *is* a boot loader. :)
You could use the bootwrapper that is in the kernel source tree
(zImage). If a zImage's entry point is at the execution entry point,
then it will start the Linux kernel correctly. However, it is still a
compressed image.
If you *really* need an uncompressed image, I would start with the
bootwrapper and hack it to work with an non-gzipped kernel image.
However, why do you want to do it this way? You probably won't gain
much in boot time and it will be more difficult to maintain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Parav Pandit @ 2006-08-02 3:49 UTC (permalink / raw)
To: Milton Miller, cthomas, linuxppc-embedded
In-Reply-To: <11153922785140e0f761.861021530.miltonm@bga.com>
--- Milton Miller <miltonm@bga.com> wrote:
> On Tue Jul 25 2006 05:30:39 PM CDT, Clint Thomas
> wrote:
>
> > Basically, the system I want linux running on does
> not require the
> > initialization of hardware that U-boot provides,
> or at least it does not
> > need it to boot the linux kernel. I want to load
> an uncompressed linux
> > kernel into memory and start the execution of the
> kernel, without using
> > any kind of bootloader. Is this possible? Or does
> linux need some kind
> > of firmware or other software to tell it to start
> executing? Thanks for
> > any info you might have.
>
> To run a powerpc (not ppc, which will be removed)
> kernel, in addition to the uncompressed kernel you
> will need to supply a device tree structure, point
> r3 to it, zero r5, and set r4 to the load address
> (zero as you have described). See
> Documentation/powerpc/booting-without-of.txt for
> details. Then arrange for you processor to start
> executing at address 0. Note that /vmlinux has an
> elf header, you can use objcopy to remove it or
> adjust r4 and your start point; the kernel will copy
> itself to 0, clear bss and set up the stack. The
> device tree structure must be placed above the bss
> space in memory, not just the initialized data.
Linux kernel does the bss cleaning after
start_kernel() even though boot loader does it. So one
step less.
Parav
>
> milton
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: RFC: Location for Device Tree Sources?
From: Li Yang-r58472 @ 2006-08-02 3:35 UTC (permalink / raw)
To: Mark A. Greer, McClintock Matthew-R56630
Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20060802003504.GA20439@mag.az.mvista.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Mark A.
> Greer
> Sent: Wednesday, August 02, 2006 8:35 AM
> To: McClintock Matthew-R56630
> Cc: linuxppc-dev@ozlabs.org; Guennadi Liakhovetski
> Subject: Re: RFC: Location for Device Tree Sources?
>=20
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > >
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >
> > I believe in his latest patches he removed this part. The device
trees
> > were not included at all and he left this point open for discussion.
>=20
> That's correct.
>=20
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.
>=20
> We already have dtc kept externally to the kernel source. Why not
> keep a single site where all things necessary to powerpc linux are
kept?
> It could house dtc, the dt attach tool, and all the dt source files.
We already have gcc out of the kernel source, but we need to have all
the source code in. :) I strongly agree to keep dts in tree, or it
will be hard to find out what the driver really does.
>=20
> I doesn't matter to me where as long as its highly available and has
> reasonable bandwidth. jdl.com? source.mvista.com? penguinppc.org?
> other?
>=20
-Leo
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Grant Likely @ 2006-08-02 3:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <1154481150.2676.3.camel@vader.jdub.homelinux.org>
On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> > On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > > >
> > > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> > >
> > > I believe in his latest patches he removed this part. The device trees
> > > were not included at all and he left this point open for discussion.
> >
> > That's correct.
> >
> > TBH, I think its wrong to keep them in the kernel source at all--yes,
> > the same argument could be made for arch/powerpc/boot but that's been
> > settled.
>
> Sorry, I have to disagree. We're talking about device tree _source_
> files here. I believe they should be included in the kernel source.
> Where that is, I don't have a particularly strong argument but they
> should be included.
I have to second that opinion. The device tree is absolutely integral
with the rest of the code/drivers needed to support a board. I say
there are stronger arguments for keeping the dts files in the kernel
source than there are for the boot wrapper.
powerpc/boot/dts makes a lot of sense to me.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Josh Boyer @ 2006-08-02 1:12 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <20060802003504.GA20439@mag.az.mvista.com>
On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> > On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> > >
> > > Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> > > sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >
> > I believe in his latest patches he removed this part. The device trees
> > were not included at all and he left this point open for discussion.
>
> That's correct.
>
> TBH, I think its wrong to keep them in the kernel source at all--yes,
> the same argument could be made for arch/powerpc/boot but that's been
> settled.
Sorry, I have to disagree. We're talking about device tree _source_
files here. I believe they should be included in the kernel source.
Where that is, I don't have a particularly strong argument but they
should be included.
>
> We already have dtc kept externally to the kernel source. Why not
> keep a single site where all things necessary to powerpc linux are kept?
> It could house dtc, the dt attach tool, and all the dt source files.
I think hosting the dtc, the dt attach tool, and pre-built dtb files for
each platform in one spot would be a good idea.
josh
^ 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