* Re: [patch 4/7] ps3: Storage Driver Probing
From: Benjamin Herrenschmidt @ 2007-05-25 22:54 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-kernel, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.62.0705252143270.2657@pademelon.sonytel.be>
On Fri, 2007-05-25 at 21:48 +0200, Geert Uytterhoeven wrote:
> > > + msleep_interruptible(ms);
> > > + if (ms < 60000)
> > > + ms <<= 1;
> >
> > Is this timeout only for the disk spinup, or also for detecting
> media
> > added at run time, like inserting a DVD? One minute timeout for
> > detecting a DVD would sound very long to me.
>
> It's not for inserting DVDs, only for new devices showing up in the
> repository.
> Apparently new devices may keep on showing up a while after boot up,
> but I
> think this matters only for the kboot kernel, that's why I went with
> the
> exponential back-off with upper limit.
Why not just have a kthread poll at 2 second interval for new devices or
removed ones ?
(And not for request processing)
Ben.
^ permalink raw reply
* Porting "prep" from ppc to powerpc.
From: Rob Landley @ 2007-05-26 2:38 UTC (permalink / raw)
To: linuxppc-dev
Is anyone already doing this? I asked around here a few weeks ago and got the
advice:
> In theory.. copy the files from ppc/platforms/prep.* to
> powerpc/platforms/prep/
> and make some Kconfigs and see what breaks :)
Unfortunately, there isn't a ppc/platforms/prep. Under arch/ppc there's:
./boot/simple/misc-prep.c
./boot/simple/prepmap.c
./boot/utils/mkprep.c
./configs/prep_defconfig
./platforms/prep_pci.c
./platforms/prep_setup.c
./syslib/prep_nvram.c
And I'm not sure which are relevant. Any hints?
Rob
^ permalink raw reply
* Re: [patch 1/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
From: Geert Uytterhoeven @ 2007-05-26 8:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1180132539.19517.2.camel@localhost.localdomain>
On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 10:36 +0200, Geert.Uytterhoeven@sonycom.com wrote:
> > -#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE)
> > +#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \
> > + defined(CONFIG_PS3_FLASH_MODULE) ||
> > defined(CONFIG_PS3_FLASH_MODULE)
>
> As I said multiple times, imho, #ifdef CONFIG_xxx_MODULE in the kernel
> is always a bug.
>
> You should always be able to build the module out of tree afteward and
> use it on a kernel that didn't have the CONFIG_xxx_MODULE set imho.
I know.
Do you know another way to allocate an aligned chunk of 256 KiB of physically
contiguous memory, possibly a long time after boot up?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Geert Uytterhoeven @ 2007-05-26 8:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Olaf Hering, linux-kernel
In-Reply-To: <1180133119.19517.11.camel@localhost.localdomain>
On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote:
> > On Fri, May 25, Geert.Uytterhoeven@sonycom.com wrote:
> >
> > > +++ b/drivers/scsi/ps3rom.c
> >
> > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> >
> > linux/highmem.h is not included to get the kmap_* prototypes.
>
> Beside, I don't see the point of using kmap on ppc64...
So what should I use instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [patch 4/7] ps3: Storage Driver Probing
From: Geert Uytterhoeven @ 2007-05-26 8:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel, Arnd Bergmann
In-Reply-To: <1180133229.19517.13.camel@localhost.localdomain>
On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 18:18 +0200, Arnd Bergmann wrote:
> > > +static u64 ps3stor_wait_for_completion(u64 devid, u64 tag,
> > > + unsigned int timeout)
> > > +{
> > > + unsigned int retries = 0;
> > > + u64 res = -1, status;
> > > +
> > > + for (retries = 0; retries < timeout; retries++) {
> > > + res =
> > lv1_storage_check_async_status(NOTIFICATION_DEVID, tag,
> > > + &status);
> > > + if (!res)
> > > + break;
> > > + set_current_state(TASK_INTERRUPTIBLE);
> > > + schedule_timeout(1);
> > > + }
> >
> > Any reason not to use msleep(1) instead of the schedule_timeout?
>
> Both look equally ugly though... do you really have to poll ?
The special notification device (NOTIFICATION_DEVID = -1) is not in the
repository and AFAIK it doesn't have an interrupt attached to it.
Note that this is used during probing only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* RE: ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
From: Mohammad Sadegh Sadri @ 2007-05-26 10:05 UTC (permalink / raw)
To: grant.likely, akonovalov, miroslaw.dach; +Cc: Linux PPC Linux PPC
dear grant
As i said i'm using ELDK 4.0 root file system via NFS
ML403 gets IP address from DHCP , mounts the root file system via NFS and t=
hen simply stops printing messages on the screen. The board is alive becaus=
e it answers ping requests.
-- VFS: Mounted root file system (nfs filesystem)
-- Freeing unused kernel memory :108k init
( No more messages after here , hyperterminal does not show anything more )
I have chosen my root file system to be /home/sadri/hld/eldk/ppc_4xx=20
(/home/sadri/hdl/eldk is eldk installation folder )
/eldk/ppc_4xx/dev contains the following node:
crw-rw-rw- 1 root root 5, 1 May 16 09:08 console
and the last line for /etc/inittab is :
# Run gettys in standard runlevels
3:2345:respawn:/sbin/mingetty --noclear console
in addition I passed the init=3D/bin/sh parameter to the kernel with no suc=
cess.=20
the link is auto negotiated at 100MBPS
I'm using OPB UART 16550.=20
I studied the ports by Mirek23 carefully and I know that his problem has be=
en the definition of SDRAM size in xparameters.h , but this is not my probl=
em. I checked that for EDK 9 it is correct.
what is your idea?
thanks
mohammad sadegh.
----------------------------------------
> Date: Wed, 23 May 2007 10:58:28 -0600
> From: grant.likely@secretlab.ca
> To: mamsadegh@hotmail.com
> Subject: Re: ML403 2.6 kernel, root file system on NFS, stops after freei=
ng unused kernel memory
> CC: linuxppc-embedded@ozlabs.org
>=20
> On 5/23/07, Mohammad Sadegh Sadri wrote:
> >
> > Hi all
> >
> > I have studied the disscussion here mainly by Mirek32 (I think this was=
the name) but unfortunately the disscussion is finished without any suita=
ble answer and solution.
> >
> > the 2.6 kernel comes up on ml403 with no problem, it gets an IP address=
from my DHCP and mounts the root file system from my NFS server , all of t=
hese are ok.
> >
> > Unfortunately , after "freeing unused kernel memory ", init , console s=
tops working however the board is alive because it answers all of my pings =
correctly. I tried to make a telnet connection to the board with no success=
. ( I'm using ELDK 4.0)
> >
> > any suggestions what is happening here?
>=20
> Is there a /dev/console node?
>=20
> try booting with init=3D/bin/sh to see if you get a console.
>=20
> Your /etc/inittab might not be starting a getty on the console device.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Space=
s. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.=
aspx&mkt=3Den-us=
^ permalink raw reply
* Re: Using Cypress EZ-Host on ML403/5
From: Peter Luan @ 2007-05-26 10:20 UTC (permalink / raw)
To: grant.likely, jacmet; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
Hi First of all, I'm a beginner, so my questions may be funny .... sorry for
that.
Any how your ideas are very valuable for me. I'm going to have the usb work
on ML403.
I have two questions about the usb on ml403 board.
1) In EDK9.1i, we can use the wizard to build a new design with usb. But I
found it's different from the reference design that xilinx provided for
edk8.1i. So which design should I choose? In datasheet of opb_epc, I found
that we should add the irq manually. So I added the irq and reset according
to xapp925. After that, I patched my linux kernel using the patch by Peter
Korsgaard. But when I pluged in the usb camera, it can't probe it. What
should I do additionally?
2) I can't find where to initialize the base registers and irq in the usb
driver for cy7c67300 provided by Peter Korsgaard. In the function
usb_c67x00_drv_probe, I found it called platform_get_resource(pdev,
IORESOURCE_MEM, 0). So I think I should add some register codes for usb like
uartlite or temac in virtex.c. I added the following codes:
#ifdef XPAR_USB_0_BASEADDR
[VIRTEX_USB_0] = {
.name = "xilix_usb",
.id = 0,
.num_resource = 2,
.resource = (struct resource[]) {
{
.start = XPAR_USB_0_BASEADDR,
.end = XPAR_USB_0_HIGHADDR,
.flags = IORESOURCE_MEM,
},
{
.start = XPAR_INTC_0_USB_0_VEC_ID,
.end = XPAR_INTC_0_USB_0_VEC_ID,
.flags = IORESOURCE_IRQ,
}
}
},
#endif
and define the following macro in xparameters_ml403.h.
#define XPAR_INTC_0_USB_0_VEC_ID XPAR_OPB_INTC_0_SYSTEM_USB_HPI_INT_INTR
#define XPAR_USB_0_BASEADDR XPAR_CYPRESS_USB_PRH0_BASEADDR
#define XPAR_USB_0_HIGHADDR XPAR_CYPRESS_USB_PRH0_HIGHADDR
After that, it still can't prob the usb device. So could you give me some
suggestion about making usb work on ml403?
Thank you very much!
Peter Luan
[-- Attachment #2: Type: text/html, Size: 10310 bytes --]
^ permalink raw reply
* RE: ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
From: Mohammad Sadegh Sadri @ 2007-05-26 13:46 UTC (permalink / raw)
To: grant.likely; +Cc: Linux PPC Linux PPC
hi
ok! problem solved
problem was kernel command line
mine was:
CONFIG_CMDLINE=3D"console=3DttyS0,9600 console=3Dtty0 root=3D/dev/nfs rw nf=
sroot=3D10.10.10.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=3Ddhcp"
by default 2.6.21 CMDLINE contains two console parameters,=20
the correct one should be=20
CONFIG_CMDLINE=3D"console=3DttyS0,9600 root=3D/dev/nfs rw nfsroot=3D10.10.1=
0.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=3Ddhcp"
well , rootfs comes up until login prompt,
I enter root as the password but it gives "incorrect login" message/
another note:
I changed the memory size to 32Mbytes from 64, I feel the system is more st=
able in this case. some times the system does not come up probperly. ( gene=
rates segmentation fault and similar messages )
thanks
----------------------------------------
> Date: Wed, 23 May 2007 10:58:28 -0600
> From: grant.likely@secretlab.ca
> To: mamsadegh@hotmail.com
> Subject: Re: ML403 2.6 kernel, root file system on NFS, stops after freei=
ng unused kernel memory
> CC: linuxppc-embedded@ozlabs.org
>=20
> On 5/23/07, Mohammad Sadegh Sadri wrote:
> >
> > Hi all
> >
> > I have studied the disscussion here mainly by Mirek32 (I think this was=
the name) but unfortunately the disscussion is finished without any suita=
ble answer and solution.
> >
> > the 2.6 kernel comes up on ml403 with no problem, it gets an IP address=
from my DHCP and mounts the root file system from my NFS server , all of t=
hese are ok.
> >
> > Unfortunately , after "freeing unused kernel memory ", init , console s=
tops working however the board is alive because it answers all of my pings =
correctly. I tried to make a telnet connection to the board with no success=
. ( I'm using ELDK 4.0)
> >
> > any suggestions what is happening here?
>=20
> Is there a /dev/console node?
>=20
> try booting with init=3D/bin/sh to see if you get a console.
>=20
> Your /etc/inittab might not be starting a getty on the console device.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Space=
s. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.=
aspx&mkt=3Den-us=
^ permalink raw reply
* Re: [patch 1/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
From: Benjamin Herrenschmidt @ 2007-05-26 22:17 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.62.0705261050140.2657@pademelon.sonytel.be>
On Sat, 2007-05-26 at 10:51 +0200, Geert Uytterhoeven wrote:
>
> I know.
>
> Do you know another way to allocate an aligned chunk of 256 KiB of
> physically
> contiguous memory, possibly a long time after boot up?
kmalloc & a good prayer ? :-0
Ben.
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-05-26 22:18 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Olaf Hering, linux-kernel
In-Reply-To: <Pine.LNX.4.62.0705261052110.2657@pademelon.sonytel.be>
On Sat, 2007-05-26 at 10:52 +0200, Geert Uytterhoeven wrote:
> On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> > On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote:
> > > On Fri, May 25, Geert.Uytterhoeven@sonycom.com wrote:
> > >
> > > > +++ b/drivers/scsi/ps3rom.c
> > >
> > > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > >
> > > linux/highmem.h is not included to get the kmap_* prototypes.
> >
> > Beside, I don't see the point of using kmap on ppc64...
>
> So what should I use instead?
you don't need to map ... the linear mapping is there.... page_address()
should just work. But then, kmap will resolve to just that anyway so I
suppose it doesn't matter.
Ben.
^ permalink raw reply
* powerpc: Fix possible access to free pages
From: Benjamin Herrenschmidt @ 2007-05-27 5:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
I think whe have a subtle race on ppc64 with the tlb batching. The
common code expects tlb_flush() to actually flush any pending TLB
batch. In does that because it delays all page freeing until after
tlb_flush() is called, in order to ensure no stale reference to
those pages exist in any TLB, thus causing potential access to
the freed data.
However, our tlb_flush only triggers the RCU for freeing page
table pages, it does not currently trigger a flush of a pending
TLB/hash batch, which is, I think, an error. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-powerpc/tlb.h
===================================================================
--- linux-work.orig/include/asm-powerpc/tlb.h 2007-05-27 15:09:01.000000000 +1000
+++ linux-work/include/asm-powerpc/tlb.h 2007-05-27 15:09:12.000000000 +1000
@@ -38,6 +38,15 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
+ struct ppc64_tlb_batch *tlbbatch = &__get_cpu_var(ppc64_tlb_batch);
+
+ /* If there's a TLB batch pending, then we must flush it because the
+ * pages are going to be freed and we really don't want to have a CPU
+ * access a freed page because it has a stale TLB
+ */
+ if (tlbbatch->index)
+ __flush_tlb_pending(tlbbatch);
+
pte_free_finish();
}
^ permalink raw reply
* powerpc: Fix possible access to free pages
From: Benjamin Herrenschmidt @ 2007-05-27 5:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
I think whe have a subtle race on ppc64 with the tlb batching. The
common code expects tlb_flush() to actually flush any pending TLB
batch. In does that because it delays all page freeing until after
tlb_flush() is called, in order to ensure no stale reference to
those pages exist in any TLB, thus causing potential access to
the freed data.
However, our tlb_flush only triggers the RCU for freeing page
table pages, it does not currently trigger a flush of a pending
TLB/hash batch, which is, I think, an error. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-powerpc/tlb.h
===================================================================
--- linux-work.orig/include/asm-powerpc/tlb.h 2007-05-27 15:09:01.000000000 +1000
+++ linux-work/include/asm-powerpc/tlb.h 2007-05-27 15:09:12.000000000 +1000
@@ -38,6 +38,15 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
+ struct ppc64_tlb_batch *tlbbatch = &__get_cpu_var(ppc64_tlb_batch);
+
+ /* If there's a TLB batch pending, then we must flush it because the
+ * pages are going to be freed and we really don't want to have a CPU
+ * access a freed page because it has a stale TLB
+ */
+ if (tlbbatch->index)
+ __flush_tlb_pending(tlbbatch);
+
pte_free_finish();
}
^ permalink raw reply
* Re: [i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.
From: Matt Sealey @ 2007-05-27 9:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <c829bacbfbea66b31629372cf6cc2c1b@kernel.crashing.org>
Segher Boessenkool wrote:
>> Like you said, that's just my opinion on it, but I have
>> seen too many people nag at Genesi/bplan for the quirks
>> in our device tree, and a lot of effort went into making
>> our device trees fit the expectations of Linux where it
>> was absolutely forced upon us by Linux driver writers.
>
> You could have avoided most of those problems by working
> with us from the start. Developing in a hidden corner
> for months and then dropping all your code on us seldom
> gives the results you hope for. Anyway, let's not rehash
> *that* discussion.
*Rubbish/Rehash*. When we started firmware development for
the Efika (ahem, mid-2005) there was NO mpc52xx device tree
specification.
Even if you do have a device tree specification I think it
has been somewhat tainted by it being written by the driver
developers, who are not so much hell-bent on writing a great
spec as hell-bent on making their code easier on the eyes
of the people who ACK it.
And lastly, the real crime here is that absolutely NO input
was attempted to be gained from the developers of the ONLY
open-firmware 5200B board on the planet, at the time. It
was just written, and pushed out there, and then it was
asked "why aren't bplan following our specification?!?!"
~
I really do not think it is a problem for a device to be
called "usb-ohci" in the device tree, with a property for
"big-endian". Or perhaps, "irda" with a compatible for
"psc-irda". Without the chip specifier. I also do not think
it is a problem for the device driver to look at the parent
bus node or soc node or platform node or builtin node or
whatever else, to find out more information about the driver.
Naming these nodes with long-winded device-inclusive names
in the first place is a difficult to understand shortcut
which provides no reasonable benefits.
Ostensibly, with an OCHI USB controller, they are all the
same anyway (it's a register definition, the only variable
points being where it starts and whether you use big endian
or little endian values), so why give it a special name?
If you have 6 chips which implement the same Freescale OHCI
controller but with varying levels of compliance, they are
still all OHCI controllers. And you can tell which OHCI
quirks you need to fix up in the driver, by.. looking at
the chip it's running on. The controller itself would never,
ever tell you how broken it is in real life. I don't
think encapsulation problems exist here. You want to support
a device but quirk out some specific chip revisions it's
built into, well, you need to find the device, then find out
the chip it's in, if in fact it's in a chip at all (if it's
not, then it could be a PCI device, in which case the
details of that are in the PCI config space, without a doubt.
Since most x86 chipset drivers do not look at device trees
they are implementing blacklists, id checks and tweaking
values to see the effects - isn't it code sharing to let
the ppc-compiled version of the same driver do the same
tests, rather than compile it out, add all new code to
determine it's capabilities from a device tree, which may
not have been written to fully determine the device quirks
of 10,000,000 PCI devices in the world possible of being
plugged into a PCI slot?). This is why I artificially limit
it to SoC's.
What is the effect if the device never changes over the
lifetime of the chip and you started calling it "mpc5200-usb"
to start with? Well, every device has to list "compatible"
for at least one chip which may well be very far removed,
I think that is an ugly solution in terms of the namespace.
If a device driver knows about certain chip revisions and
needs only to make small quirks and changes happen in the
device driver, naming it "mpc5200-usb" and "mpc5200b-usb"
and "mpc5121e-usb" and "mpc5900-usb" over and over makes
no benefit to the small modifications required.
As compared to, for instance, calling it "usb-ohci", giving
it a "big-endian" property, then looking at the parent
node, seeing if it's an "soc" node, looking at the model
property to check the chip revision or board revision, and
implementing the quirks, I don't see why this is any different
to the way you wanted to have it done in the first place. In
fact I think it's a more portable, more true-to-OF-specs
way of doing it.
And in fact, if there is no point whatsoever to implementing
the soc model property since all the child nodes need to be
encapsulated, why bother having it there? it's an optional
property in the specs.
If I had my way I'd be rewriting your device tree specs for
the MPC52xx now, but that would only burden the guys at
bplan writing the firmware to model new revisions against a
new device tree spec, which is a waste of time. We're stuck
with what you all jotted down one day, and expected all
device vendors to follow without nary a consultation, and
you yourself have admitted there, that some parts of it are
written and the authors seem to have gone a little overboard
on it. Now it is written, it is practically fixed, so what
do we do about it?
Is there some future process that can be determined which
stops brand new devices being released, reverse engineered
by Linux developers and then have the device vendors
hammered with a "linuxised" device tree they must then
certainly match for fear of derision, a device tree which
on a real and unbiased review, would probably be picked to
fault itself?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Please pull powerpc.git for_paulus branch (fwd)
From: Kumar Gala @ 2007-05-27 13:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras
Linus,
If you don't mind pulling this branch that would be great. Paul seems to
have disappeared for a few days and I want to make sure we get these fixes
in before 2.6.22.
If you'd like a re-base on your tree let me know.
- k
---------- Forwarded message ----------
Date: Wed, 23 May 2007 09:53:20 -0500 (CDT)
From: Kumar Gala <galak@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Please pull powerpc.git for_paulus branch
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
to receive the following updates:
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/dts/lite5200.dts | 2 +-
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
arch/powerpc/mm/pgtable_32.c | 2 +-
arch/powerpc/platforms/chrp/pegasos_eth.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
arch/powerpc/sysdev/qe_lib/Kconfig | 4 +---
arch/ppc/kernel/entry.S | 18 +++++++++++++++---
arch/ppc/kernel/ppc_ksyms.c | 2 --
arch/ppc/mm/hashtable.S | 20 ++++++++++++++++----
arch/ppc/mm/pgtable.c | 2 +-
drivers/macintosh/Kconfig | 1 -
drivers/net/Kconfig | 1 -
13 files changed, 39 insertions(+), 20 deletions(-)
Domen Puncer (1):
[POWERPC] 52xx: unbreak lite5200 dts (_pic vs. -pic)
Kumar Gala (5):
[PPC] Fix COMMON symbol warnings
[PPC] Remove duplicate export of __div64_32.
[POWERPC] Fix modpost warning
[PPC] Fix modpost warning
[POWERPC] Fix Kconfig warning
Li Yang (1):
[POWERPC] Fix Section mismatch warnings
Timur Tabi (1):
[POWERPC] QE: fix Kconfig 'select' warning with UCC_FAST
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 56d3c0d..5eaeafd 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -118,6 +118,7 @@ config GENERIC_BUG
depends on BUG
config SYS_SUPPORTS_APM_EMULATION
+ default y if PMAC_APM_EMU
bool
config DEFAULT_UIMAGE
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index eae68ab..d29308f 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -67,7 +67,7 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200_pic";
+ compatible = "mpc5200-pic";
reg = <500 80>;
built-in;
};
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 5185625..f242531 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -67,7 +67,7 @@
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
- compatible = "mpc5200b-pic\0mpc5200_pic";
+ compatible = "mpc5200b-pic\0mpc5200-pic";
reg = <500 80>;
built-in;
};
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d8232b7..f6ae1a5 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -93,7 +93,7 @@ void pgd_free(pgd_t *pgd)
free_pages((unsigned long)pgd, PGDIR_ORDER);
}
-pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
+__init_refok pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
{
pte_t *pte;
extern int mem_init_done;
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 7104567..5bcc58d 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -169,7 +169,7 @@ static int Enable_SRAM(void)
/***********/
/***********/
-int mv643xx_eth_add_pds(void)
+static int __init mv643xx_eth_add_pds(void)
{
int ret = 0;
static struct pci_device_id pci_marvell_mv64360[] = {
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index a410bc7..07b1c4e 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -384,7 +384,7 @@ int boot_part;
static dev_t boot_dev;
#ifdef CONFIG_SCSI
-void __init note_scsi_host(struct device_node *node, void *host)
+void note_scsi_host(struct device_node *node, void *host)
{
int l;
char *p;
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
index 887739f..f611d34 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -5,15 +5,13 @@
config UCC_SLOW
bool
default n
- select UCC
help
This option provides qe_lib support to UCC slow
protocols: UART, BISYNC, QMC
config UCC_FAST
bool
- default n
- select UCC
+ default y if UCC_GETH
help
This option provides qe_lib support to UCC fast
protocols: HDLC, Ethernet, ATM, transparent
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index ab64256..fba7ca1 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -596,7 +596,11 @@ fast_exception_return:
mr r12,r4 /* restart at exc_exit_restart */
b 2b
- .comm fee_restarts,4
+ .section .bss
+ .align 2
+fee_restarts:
+ .space 4
+ .previous
/* aargh, a nonrecoverable interrupt, panic */
/* aargh, we don't know which trap this is */
@@ -851,7 +855,11 @@ load_dbcr0:
mtspr SPRN_DBSR,r11 /* clear all pending debug events */
blr
- .comm global_dbcr0,8
+ .section .bss
+ .align 4
+global_dbcr0:
+ .space 8
+ .previous
#endif /* !(CONFIG_4xx || CONFIG_BOOKE) */
do_work: /* r10 contains MSR_KERNEL here */
@@ -926,4 +934,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_601)
/* shouldn't return */
b 4b
- .comm ee_restarts,4
+ .section .bss
+ .align 2
+ee_restarts:
+ .space 4
+ .previous
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 4ad4996..a416520 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -40,7 +40,6 @@
#include <asm/time.h>
#include <asm/cputable.h>
#include <asm/btext.h>
-#include <asm/div64.h>
#include <asm/xmon.h>
#include <asm/signal.h>
#include <asm/dcr.h>
@@ -93,7 +92,6 @@ EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
EXPORT_SYMBOL(strlen);
EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(__div64_32);
EXPORT_SYMBOL(csum_partial);
EXPORT_SYMBOL(csum_partial_copy_generic);
diff --git a/arch/ppc/mm/hashtable.S b/arch/ppc/mm/hashtable.S
index e756942..5f364dc 100644
--- a/arch/ppc/mm/hashtable.S
+++ b/arch/ppc/mm/hashtable.S
@@ -30,7 +30,11 @@
#include <asm/asm-offsets.h>
#ifdef CONFIG_SMP
- .comm mmu_hash_lock,4
+ .section .bss
+ .align 2
+ .globl mmu_hash_lock
+mmu_hash_lock:
+ .space 4
#endif /* CONFIG_SMP */
/*
@@ -461,9 +465,17 @@ found_slot:
sync /* make sure pte updates get to memory */
blr
- .comm next_slot,4
- .comm primary_pteg_full,4
- .comm htab_hash_searches,4
+ .section .bss
+ .align 2
+next_slot:
+ .space 4
+ .globl primary_pteg_full
+primary_pteg_full:
+ .space 4
+ .globl htab_hash_searches
+htab_hash_searches:
+ .space 4
+ .previous
/*
* Flush the entry for a particular page from the hash table.
diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
index c023b72..35ebb63 100644
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -92,7 +92,7 @@ void pgd_free(pgd_t *pgd)
free_pages((unsigned long)pgd, PGDIR_ORDER);
}
-pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
+__init_refok pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
{
pte_t *pte;
extern int mem_init_done;
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 58926da..f44c94a 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -113,7 +113,6 @@ config PMAC_SMU
config PMAC_APM_EMU
tristate "APM emulation"
- select SYS_SUPPORTS_APM_EMULATION
select APM_EMULATION
depends on ADB_PMU && PM
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c5baa19..3b204ba 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2280,7 +2280,6 @@ config GFAR_NAPI
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
- select UCC_FAST
help
This driver supports the Gigabit Ethernet mode of the QUICC Engine,
which is available on some Freescale SOCs.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
From: Clemens Koller @ 2007-05-27 17:34 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W15A8C3F50BF6AA5251BAB9B22A0@phx.gbl>
Hi, Mohammed!
Mohammad Sadegh Sadri schrieb:
> ok! problem solved
> problem was kernel command line
> mine was:
>
> CONFIG_CMDLINE="console=ttyS0,9600 console=tty0 root=/dev/nfs rw nfsroot=10.10.10.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=dhcp"
>
> by default 2.6.21 CMDLINE contains two console parameters,
> the correct one should be
>
> CONFIG_CMDLINE="console=ttyS0,9600 root=/dev/nfs rw nfsroot=10.10.10.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=dhcp"
>
> well , rootfs comes up until login prompt,
> I enter root as the password but it gives "incorrect login" message/
I have had the same symptoms.
Some device node was missing. I guess it was something like:
crw--w--w- 1 root tty 5, 1 May 1 09:30 console
crw-rw-rw- 1 root tty 5, 0 May 27 10:14 tty
Also check
-----8<-----
#
# /etc/securetty: defines which devices root can log in on
#
console
ttyS0
tty1
tty2
tty3
tty4
tty5
tty6
# End of file
-----8<-----
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [patch 1/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
From: Arnd Bergmann @ 2007-05-27 18:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, linux-kernel
In-Reply-To: <1180217870.19517.39.camel@localhost.localdomain>
On Sunday 27 May 2007, Benjamin Herrenschmidt wrote:
> On Sat, 2007-05-26 at 10:51 +0200, Geert Uytterhoeven wrote:
> > Do you know another way to allocate an aligned chunk of 256 KiB of
> > physically
> > contiguous memory, possibly a long time after boot up?
>
> kmalloc & a good prayer ? :-0
s/kmalloc/get_free_pages/
kmalloc is limited to 128kb.
Arnd <><
^ permalink raw reply
* Re: Porting "prep" from ppc to powerpc.
From: David Gibson @ 2007-05-27 23:20 UTC (permalink / raw)
To: Rob Landley; +Cc: linuxppc-dev
In-Reply-To: <200705252238.39819.rob@landley.net>
On Fri, May 25, 2007 at 10:38:39PM -0400, Rob Landley wrote:
> Is anyone already doing this? I asked around here a few weeks ago and got the
> advice:
>
> > In theory.. copy the files from ppc/platforms/prep.* to
> > powerpc/platforms/prep/
> > and make some Kconfigs and see what breaks :)
Actually, I don't really recommend that method in any case.
Instead I suggest making a Kconfig under arch/powerpc, then adding
things until it builds, then adding things until it boots. When you
need to know what has to be done at a particular point, consult
arch/ppc.
> Unfortunately, there isn't a ppc/platforms/prep. Under arch/ppc there's:
>
> ./boot/simple/misc-prep.c
> ./boot/simple/prepmap.c
> ./boot/utils/mkprep.c
> ./configs/prep_defconfig
> ./platforms/prep_pci.c
> ./platforms/prep_setup.c
> ./syslib/prep_nvram.c
>
> And I'm not sure which are relevant. Any hints?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: David Gibson @ 2007-05-27 23:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <25433b8fc06678e73ee055ed4f44f7a3@kernel.crashing.org>
On Fri, May 25, 2007 at 04:11:59PM +0200, Segher Boessenkool wrote:
> > Waah! Third time lucky?
>
> You wish :-)
>
> > - Second, the PHYs give only "bcm54xx" as a compatible
> > property. This is unfortunate, because there are many bcm54xx PHY
> > models, and they have differences which can matter. We add a more
> > precise compatible string, giving the precise PHY model (bcm5461A in
> > this case).
>
> You completely removed the "compatible" properties instead.
> Bad idea.
Um... weren't you the one that was just saying compatible properties
aren't necessary if you can distinguish the hardware in other ways?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: David Gibson @ 2007-05-27 23:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Alexandre Bounine
In-Reply-To: <1180101831.3360.38.camel@zod.rchland.ibm.com>
On Fri, May 25, 2007 at 09:03:51AM -0500, Josh Boyer wrote:
> On Fri, 2007-05-25 at 14:38 +1000, David Gibson wrote:
> >
> > Waah! Third time lucky?
>
> Not quite. :)
>
> > - Second, the PHYs give only "bcm54xx" as a compatible
> > property. This is unfortunate, because there are many bcm54xx PHY
> > models, and they have differences which can matter. We add a more
> > precise compatible string, giving the precise PHY model (bcm5461A in
> > this case).
>
> You don't actually do this. Instead, you specify a
> txc-rxc-delay-disable property.
Oops, forgot to update the patch description.
> > - PHY1: ethernet-phy@6000 {
> > - device_type = "ethernet-phy";
> > - compatible = "bcm54xx";
> > - reg = <6000 50>;
> > - phy-id = <1>;
> > + PHY1: ethernet-phy@1 {
> > + reg = <1>;
> > + txc-rxc-delay-disable;
> > };
>
> I would have rather we left the compatible = "bmc5461A" as well. Though
> perhaps a comment would suffice instead.
Hrm, I was tending to go with Kumar's point that it's kind of simpler
and safer to probe the PHY type directly.
> > Index: working-2.6/arch/powerpc/sysdev/tsi108_dev.c
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/sysdev/tsi108_dev.c 2007-05-25 14:34:00.000000000 +1000
> > +++ working-2.6/arch/powerpc/sysdev/tsi108_dev.c 2007-05-25 14:38:32.000000000 +1000
>
> > +
> > tsi_eth_data.regs = r[0].start;
> > tsi_eth_data.phyregs = res.start;
> > tsi_eth_data.phy = *phy_id;
> > tsi_eth_data.irq_num = irq_of_parse_and_map(np, 0);
> > - if (of_device_is_compatible(phy, "bcm54xx"))
> > +
> > + if (of_get_property(phy, "txc-rxc-delay-disable", NULL))
> > tsi_eth_data.phy_type = TSI108_PHY_BCM54XX;
> > of_node_put(phy);
>
> At the very least this needs a comment explaining what exactly is being
> done here. Right now, it's looking for some magical property and
> setting the PHY type to a Broadcom PHY... very confusing to someone
> that hasn't followed the email thread.
Yeah, good point. And more specifically I should put a FIXME comment
in, saying that the ethernet driver itself should be changed to
implement this workaround in a different way, rather than based on
this phy_type field, since the workaround isn't really related to the
PHY type. I was assuming that cleanup would happen as part of the
port to phylib.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] ps3/interrupt.c uses get_hard_smp_processor_id
From: Stephen Rothwell @ 2007-05-28 0:19 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, cbe-oss-dev
and so needs to include asm/smp.h for a UP build to work.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/ps3/interrupt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 9da82c2..ec9030d 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -25,6 +25,7 @@
#include <asm/machdep.h>
#include <asm/udbg.h>
#include <asm/lv1call.h>
+#include <asm/smp.h>
#include "platform.h"
--
1.5.1.4
^ permalink raw reply related
* [PATCH] [POWERPC] pasemi idle uses hard_smp_processor_id
From: Stephen Rothwell @ 2007-05-28 0:20 UTC (permalink / raw)
To: paulus; +Cc: Olof Johansson, ppc-dev
and so needs to include asm/smp.h so a UP build works.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pasemi/idle.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 03cd45d..3c962d5 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -26,6 +26,7 @@
#include <asm/machdep.h>
#include <asm/reg.h>
+#include <asm/smp.h>
#include "pasemi.h"
--
1.5.1.4
^ permalink raw reply related
* Re: Please pull powerpc.git for_paulus branch (fwd)
From: Benjamin Herrenschmidt @ 2007-05-28 1:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0705270856560.4113@gate.crashing.org>
On Sun, 2007-05-27 at 08:58 -0500, Kumar Gala wrote:
> Linus,
>
> If you don't mind pulling this branch that would be great. Paul seems to
> have disappeared for a few days and I want to make sure we get these fixes
> in before 2.6.22.
>
> If you'd like a re-base on your tree let me know.
I do mind however... this touches the hash table MMU code which is
something that needs to be acked by paulus or me at the very least.
Cheers,
Ben.
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Benjamin Herrenschmidt @ 2007-05-28 1:38 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070527233031.GB23768@localhost.localdomain>
On Mon, 2007-05-28 at 09:30 +1000, David Gibson wrote:
> On Fri, May 25, 2007 at 04:11:59PM +0200, Segher Boessenkool wrote:
> > > Waah! Third time lucky?
> >
> > You wish :-)
> >
> > > - Second, the PHYs give only "bcm54xx" as a compatible
> > > property. This is unfortunate, because there are many bcm54xx PHY
> > > models, and they have differences which can matter. We add a more
> > > precise compatible string, giving the precise PHY model (bcm5461A in
> > > this case).
> >
> > You completely removed the "compatible" properties instead.
> > Bad idea.
>
> Um... weren't you the one that was just saying compatible properties
> aren't necessary if you can distinguish the hardware in other ways?
In that case however, the 54xx are fairly different from each other, so
please use something more specific.
Ben.
^ permalink raw reply
* Re: Please pull powerpc.git for_paulus branch (fwd)
From: Paul Mackerras @ 2007-05-28 1:52 UTC (permalink / raw)
To: Kumar Gala, Linus Torvalds; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0705270856560.4113@gate.crashing.org>
Kumar Gala writes:
> If you don't mind pulling this branch that would be great. Paul seems to
> have disappeared for a few days and I want to make sure we get these fixes
> in before 2.6.22.
Sorry, I got busy with other things.
Linus, the changes look OK to pull, although I still don't understand
why using .comm in assembler code is suddenly verboten...
Paul.
^ permalink raw reply
* [PATCH] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Zang Roy-r61911 @ 2007-05-28 2:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/boot/Makefile | 4 +-
arch/powerpc/boot/cuboot-hpc2.c | 57 ++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc7448hpc2.dts | 5 ++
arch/powerpc/boot/ppcboot.h | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 1 +
include/asm-ppc/ppcboot.h | 2 +-
6 files changed, 68 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hpc2.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8378898..5fa515d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
gunzip_util.c elf_util.c $(zlib) devtree.c \
44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c
+ cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ cuboot-hpc2.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -142,6 +143,7 @@ ifneq ($(CONFIG_DEVICE_TREE),"")
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
+image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
new file mode 100644
index 0000000..d8f01c4
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hpc2.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+#define TARGET_TSI108_BRIDGE
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _end[];
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ unsigned long end_of_ram = bd.bi_memstart + bd.bi_memsize;
+ unsigned long avail_ram = end_of_ram - (unsigned long)_end;
+
+ memcpy(&bd, (bd_t *)r3, sizeof(bd));
+ loader_info.initrd_addr = r4;
+ loader_info.initrd_size = r4 ? r5 - r4 : 0;
+ loader_info.cmdline = (char *)r6;
+ loader_info.cmdline_len = r7 - r6;
+
+ simple_alloc_init(_end, avail_ram - 1024*1024, 32, 64);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 765c306..a2ee94f 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -81,6 +81,7 @@
};
ethernet@6200 {
+ linux,network-index = <0>;
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH";
@@ -93,6 +94,7 @@
};
ethernet@6600 {
+ linux,network-index = <1>;
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -188,5 +190,8 @@
};
};
};
+ chosen {
+ linux,stdout-path = "/tsi108@c0000000/serial@7808";
+ };
};
diff --git a/arch/powerpc/boot/ppcboot.h b/arch/powerpc/boot/ppcboot.h
index 5290ff2..f7ef004 100644
--- a/arch/powerpc/boot/ppcboot.h
+++ b/arch/powerpc/boot/ppcboot.h
@@ -78,7 +78,7 @@ typedef struct bd_info {
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
#if defined(TARGET_EVB64260) || defined(TARGET_405EP) || defined(TARGET_44x) || \
- defined(TARGET_85xx) || defined(TARGET_83xx)
+ defined(TARGET_85xx) || defined(TARGET_83xx) || defined(TARGET_TSI108_BRIDGE)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#define HAVE_ENET1ADDR
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index f2d2626..9a6c6c2 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -20,6 +20,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select WANT_DEVICE_TREE
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
diff --git a/include/asm-ppc/ppcboot.h b/include/asm-ppc/ppcboot.h
index 6b7b63f..eb6e18d 100644
--- a/include/asm-ppc/ppcboot.h
+++ b/include/asm-ppc/ppcboot.h
@@ -74,7 +74,7 @@ typedef struct bd_info {
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
#if defined(CONFIG_EVB64260) || defined(CONFIG_405EP) || defined(CONFIG_44x) || \
- defined(CONFIG_85xx) || defined(CONFIG_83xx)
+ defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_TSI108_BRIDGE)
/* second onboard ethernet port */
unsigned char bi_enet1addr[6];
#endif
--
1.5.1
^ permalink raw reply related
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