* Re: 832x: MATH_EMUL
From: Kumar Gala @ 2009-08-21 6:55 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4A8E4128.6040905@denx.de>
On Aug 21, 2009, at 1:39 AM, Heiko Schocher wrote:
> Hello,
>
> I actually porting a mpc8321 based port, and because there is no FPU
> on this CPU, I activated MATH_EMUL, as all other mpc832x ports did.
>
> Is there something like a counter, which counts how many times this
> Exception occurs?
Geert published some patches that did something like this but there
isn't upstream as far as I know at this point.
- k
^ permalink raw reply
* Re: [Bugme-new] [Bug 14021] New: hfsplus caused data loss
From: Benjamin Herrenschmidt @ 2009-08-21 7:29 UTC (permalink / raw)
To: Andrew Morton
Cc: bugzilla-daemon, rbrito, linuxppc-dev, bugme-daemon,
linux-fsdevel
In-Reply-To: <20090820150242.a4b5eccc.akpm@linux-foundation.org>
On Thu, 2009-08-20 at 15:02 -0700, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
Is Roman Zippel still around ? (I added him to the CC list). AFAIK, He
maintains HFS and HFS+ (and was the last one to do any major work on
them).
Cheers,
Ben.
> On Thu, 20 Aug 2009 02:17:21 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=14021
> >
> > Summary: hfsplus caused data loss
> > Product: File System
> > Version: 2.5
> > Kernel Version: 2.6.31-rc5
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: HFS/HFSPLUS
> > AssignedTo: zippel@linux-m68k.org
> > ReportedBy: rbrito@ime.usp.br
> > Regression: Yes
> >
> >
> > Hi.
> >
> > I am trying to package a new version of Apple's own fsck/mkfs for HFS+
> > filesystems so that they can be used in Linux as a way to transfer data among
> > computers, but I had quite a surprise when I was using the hfsplus module.
> >
> > I just created a 100MB file with nulls (dd if=/dev/null ...) and I created an
> > HFS+ filesystem on it.
> >
> > Then, I loop mounted it and tried to use it a little bit (in particular,
> > applying patches with quilt on a source tree). The commands spit some errors
> > about not being able to create links (I never had that problem before) and the
> > directory where I was became empty!
> >
> > Furthermore, here is a quite, quite strange directory listing:
> >
> > ,----
> > | rbrito@chagas:/media/usb7$ ls -lAF
> > | ls: hfsprogs_332.14-7.diff.gz: No such file or directory
> > | ls: hfsprogs_332.14-7.dsc: No such file or directory
> > | ls: hfsprogs_332.14.orig.tar.gz: No such file or directory
> > | ls: hfsprogs_332.18-1.diff.gz: No such file or directory
> > | ls: hfsprogs_332.18-1.dsc: No such file or directory
> > | ls: hfsprogs_332.18-1_amd64.changes: No such file or directory
> > | ls: hfsprogs_332.18-1_amd64.deb: No such file or directory
> > | ls: hfsprogs_332.18.orig.tar.gz: No such file or directory
> > | total 1636
> > | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
> > | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
> > | drwxr-xr-x 1 rbrito rbrito 45 Aug 17 15:30 hfsprogs-332.18/
> > | -rw-r--r-- 1 rbrito rbrito 35609 Aug 17 08:13 hfsprogs_332.14-7.diff.gz
> > | -rw-r--r-- 1 rbrito rbrito 1193 Aug 17 08:13 hfsprogs_332.14-7.dsc
> > | -rw-r--r-- 1 rbrito rbrito 714035 Aug 17 08:13 hfsprogs_332.14.orig.tar.gz
> > | -rw-r--r-- 1 rbrito rbrito 35342 Aug 17 15:26 hfsprogs_332.18-1.diff.gz
> > | -rw-r--r-- 1 rbrito rbrito 954 Aug 17 15:26 hfsprogs_332.18-1.dsc
> > | -rw-r--r-- 1 rbrito rbrito 2148 Aug 17 15:26
> > hfsprogs_332.18-1_amd64.changes
> > | -rw-r--r-- 1 rbrito rbrito 135398 Aug 17 15:26 hfsprogs_332.18-1_amd64.deb
> > | -rw-r--r-- 1 rbrito rbrito 732449 Aug 17 08:35 hfsprogs_332.18.orig.tar.gz
> > | rbrito@chagas:/media/usb7$
> > `----
> >
> > I am using kernel 2.6.31-rc5-1rb.pre6 (that is, rc5 with git updates up to one
> > or two days before rc6).
> >
> > There are no messages in the dmesg, besides these:
> >
> > ,----
> > | [30991.501804] loop: module loaded
> > | [30991.513337] hfs: create hidden dir...
> > | [39897.867830] hfs: create hidden dir...
> > | [39960.061622] hfs: splitting index node...
> > `----
> >
> > No stack traces, no nothing. Oh, I still have the disk image that I created, if
> > it is of any interest.
> >
> > Please let me know if I can provide any further information.
> >
>
> Gee. Nobody really does much maintenance work on hfs/hfsplus any more.
> I cc'ed the ppc guys as I expect that most HFS users are over there.
>
> It seems like a pretty gross failure - others should be hitting it.
>
> I wonder if it's a weird interaction with the loop driver.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [Bugme-new] [Bug 14021] New: hfsplus caused data loss
From: Andrew Morton @ 2009-08-21 7:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: bugzilla-daemon, rbrito, linuxppc-dev, bugme-daemon,
linux-fsdevel
In-Reply-To: <1250839741.17238.4.camel@pasglop>
On Fri, 21 Aug 2009 17:29:01 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2009-08-20 at 15:02 -0700, Andrew Morton wrote:
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> Is Roman Zippel still around ? (I added him to the CC list). AFAIK, He
> maintains HFS and HFS+ (and was the last one to do any major work on
> them).
I don't think I've heard from Roman since January of this year.
^ permalink raw reply
* Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
From: Stefan Roese @ 2009-08-21 7:59 UTC (permalink / raw)
To: u-boot; +Cc: linuxppc-dev, Feng Kan, linux-mtd, Sean MacLennan
In-Reply-To: <4A8DDF72.2080808@amcc.com>
Hi Feng,
On Friday 21 August 2009 01:42:42 Feng Kan wrote:
> We had a board with high number of correctable ECC errors. Which crashed
> the jffs when it
> was miss correcting the wrong byte location.
OK, thanks.
> Do you want me to submit a patch for this, or do you prefer to do it.
Sure, please go ahead and send a patch to fix this in U-Boot as well.
Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
From: Stefan Roese @ 2009-08-21 8:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, Feng Kan, David Woodhouse, linux-mtd
In-Reply-To: <1250813957-1786-1-git-send-email-fkan@amcc.com>
On Friday 21 August 2009 02:19:17 Feng Kan wrote:
> Fix ECC Correction bug where the byte offset location were double
> fliped causing correction routine to toggle the wrong byte location
> in the ECC segment. The ndfc_calculate_ecc routine change the order
> of getting the ECC code.
> /* The NDFC uses Smart Media (SMC) bytes order */
> ecc_code[0] = p[2];
> ecc_code[1] = p[1];
> ecc_code[2] = p[3];
> But in the Correction algorithm when calculating the byte offset
> location, the b1 is used as the upper part of the address. Which
> again reverse the order making the final byte offset address
> location incorrect.
> byte_addr = (addressbits[b1] << 4) + addressbits[b0];
> The order is change to read it in straight and let the correction
> function to revert it to SMC order.
>
> Signed-off-by: Feng Kan <fkan@amcc.com>
> Acked-by: Victor Gallardo <vgallardo@amcc.com>
> Acked-by: Prodyut Hazarika <phazarika@amcc.com>
Acked-by: Stefan Roese <sr@denx.de>
Would be great if we could get this fix into 2.6.31.
Cheers,
Stefan
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/405ex: provide necessary fixup function to support cuImage
From: Josh Boyer @ 2009-08-21 11:49 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4A8E37F4.60806@windriver.com>
On Fri, Aug 21, 2009 at 02:00:20PM +0800, tiejun.chen wrote:
>as I know. So I prefer to prefix with ibm405ex as you suggestion.
>
>>> diff --git a/arch/powerpc/boot/dcr.h b/arch/powerpc/boot/dcr.h
>>> index 95b9f53..ba41624 100644
>>> --- a/arch/powerpc/boot/dcr.h
>>> +++ b/arch/powerpc/boot/dcr.h
>>> @@ -153,6 +153,18 @@ static const unsigned long sdram_bxcr[] = { SDRAM0_B0CR, SDRAM0_B1CR,
>>> #define DCRN_CPC0_PLLMR1 0xf4
>>> #define DCRN_CPC0_UCR 0xf5
>>>
>>> +/* 405EX Clocking Control regs */
>>> +#define CPR0_CLKUPD 0x0020
>>> +#define CPR0_PLLC 0x0040
>>> +#define CPR0_PLLD 0x0060
>>> +#define CPR0_CPUD 0x0080
>>> +#define CPR0_PLBD 0x00a0
>>> +#define CPR0_OPBD 0x00c0
>>> +#define CPR0_PERD 0x00e0
>>> +#define CPR0_AHBD 0x0100
>>> +#define CPR0_ICFG 0x0140
>>
>> You duplicated the #defines right below this. Just change the comment for
>> the already existing defines to say "440GX/405EX Clock Control regs".
>
>I want to isolate 405EX with other 4xx for convenient maintaining code as my
>original. And although there are same offset as the register of 440GX, they are
>defined with different name on manual because of different design mechanism. So
>I hope we cannot be confused these when others track the codes.
That would make sense if #defines were something that really needed a lot of
maintenance, but they aren't. They are essentially static once correct. I'd
prefer not to grow another set of duplicate #defines.
Thanks.
josh
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/405ex: support cuImage via included dtb
From: Josh Boyer @ 2009-08-21 11:49 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4A8E3396.9030006@windriver.com>
On Fri, Aug 21, 2009 at 01:41:42PM +0800, tiejun.chen wrote:
>Josh Boyer wrote:
>> On Tue, Aug 18, 2009 at 10:28:04AM +0800, Tiejun Chen wrote:
>>> To support cuImage, we need to initialize the required sections and
>>> ensure that it is built.
>>>
>>> - cuboot-acadia.c cuboot-amigaone.c
>>> + cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c
>>> src-boot := $(src-wlib) $(src-plat) empty.c
>>>
>>> src-boot := $(addprefix $(obj)/, $(src-boot))
>>> @@ -192,6 +192,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
>>> image-$(CONFIG_EP405) += dtbImage.ep405
>>> image-$(CONFIG_WALNUT) += treeImage.walnut
>>> image-$(CONFIG_ACADIA) += cuImage.acadia
>>> +image-$(CONFIG_KILAUEA) += cuImage.kilauea
>>
>> I'm not thrilled with this part as cuImage is really the secondary
>> solution if the U-Boot that comes with a board if FDT aware. If you
>> have a different board that needs this, perhaps you could add the
>> target when that board support gets upstream?
>>
>
>Agreed and I will remove this line as you expect. Right?
Yep, that sounds right.
josh
^ permalink raw reply
* Re: 832x: MATH_EMUL
From: Detlev Zundel @ 2009-08-21 13:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1059A1F2-B4AA-48DC-82D6-B26D39414FA4@kernel.crashing.org>
Hi Kumar,
> On Aug 21, 2009, at 1:39 AM, Heiko Schocher wrote:
>
>> Hello,
>>
>> I actually porting a mpc8321 based port, and because there is no FPU
>> on this CPU, I activated MATH_EMUL, as all other mpc832x ports did.
>>
>> Is there something like a counter, which counts how many times this
>> Exception occurs?
>
> Geert published some patches that did something like this but there
> isn't upstream as far as I know at this point.
Were there any technical reasons or did it just slip into the cracks?
In my opinion such a counter would be *very* helpful to judge the
performance impact one suffers instead of living in ignorant bliss.
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* 4xx next branch updated
From: Josh Boyer @ 2009-08-21 13:37 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I've rebased the next branch of the 4xx tree to Ben's next branch, and added
the following commits:
Solomon Peachy (1):
powerpc/40x: Add support for the ESTeem 195E (PPC405EP) SBC
Stefan Roese (2):
powerpc/44x: Update Arches dts
powerpc/44x: Update Arches defconfig
fkan@amcc.com (1):
powerpc/44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board
I'm waiting for a couple more patches, then I'll ask Ben to pull.
josh
^ permalink raw reply
* Re: 832x: MATH_EMUL
From: Geert Uytterhoeven @ 2009-08-21 13:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hs
In-Reply-To: <1059A1F2-B4AA-48DC-82D6-B26D39414FA4@kernel.crashing.org>
On Fri, 21 Aug 2009, Kumar Gala wrote:
> On Aug 21, 2009, at 1:39 AM, Heiko Schocher wrote:
> >I actually porting a mpc8321 based port, and because there is no FPU
> >on this CPU, I activated MATH_EMUL, as all other mpc832x ports did.
> >
> >Is there something like a counter, which counts how many times this
> >Exception occurs?
>
> Geert published some patches that did something like this but there isn't
> upstream as far as I know at this point.
It's upstream: 80947e7c99c29ce3a78bdc1933b310468455a82f
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: 832x: MATH_EMUL
From: Heiko Schocher @ 2009-08-21 13:59 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Detlev Zundel
In-Reply-To: <alpine.LRH.2.00.0908211545170.16485@vixen.sonytel.be>
Hello Geert,
Geert Uytterhoeven wrote:
> On Fri, 21 Aug 2009, Kumar Gala wrote:
>> On Aug 21, 2009, at 1:39 AM, Heiko Schocher wrote:
>>> I actually porting a mpc8321 based port, and because there is no FPU
>>> on this CPU, I activated MATH_EMUL, as all other mpc832x ports did.
>>>
>>> Is there something like a counter, which counts how many times this
>>> Exception occurs?
>> Geert published some patches that did something like this but there isn't
>> upstream as far as I know at this point.
>
> It's upstream: 80947e7c99c29ce3a78bdc1933b310468455a82f
Thanks for this info!
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
From: Grant Likely @ 2009-08-21 14:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David S. Miller, linuxppc-dev
In-Reply-To: <20090821160116.b4a7b713.sfr@canb.auug.org.au>
On Fri, Aug 21, 2009 at 12:01 AM, Stephen Rothwell<sfr@canb.auug.org.au> wr=
ote:
>
> And similarly with sparc's pci_parse_of_addrs() and pci_parse_of_flags
> () ? =A0Maybe create drivers/of/pci.c (or drivers/pci/of.c)? =A0Or maybe =
they
> are still too different?
>
> There is probably scope for more consolidation there.
I agree, but I'll do those things in a separate patch. I'm making as
few code changes as possible in this patch to ease review.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
From: Grant Likely @ 2009-08-21 14:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1250834729.7625.5.camel@pasglop>
On Fri, Aug 21, 2009 at 12:05 AM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> On Thu, 2009-08-20 at 23:30 -0600, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> The PCI device tree scanning code in pci_64.c is some useful functionality.
>> It allows PCI devices to be described in the device tree instead of being
>> probed for, which in turn allows pci devices to use all of the device tree
>> facilities to describe complex PCI bus architectures like GPIO and IRQ
>> routing (perhaps not a common situation for desktop or server systems,
>> but useful for embedded systems with on-board PCI devices).
>>
>> This patch moves the device tree scanning into pci-common.c so it is
>> available for 32-bit powerpc machines too.
>
> I'd rather move it into a separate pci-of-scan.c file so we can more
> easily try to move it to drivers/of or drivers/pci for use by other
> archs later on.
Okay, I'll do that.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
From: Stephen Rothwell @ 2009-08-21 15:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, David S. Miller
In-Reply-To: <fa686aa40908210754s5e54af99sdbd11eb6ec48b5f9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
Hi Grant,
On Fri, 21 Aug 2009 08:54:25 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> On Fri, Aug 21, 2009 at 12:01 AM, Stephen Rothwell<sfr@canb.auug.org.au> wrote:
> >
> > And similarly with sparc's pci_parse_of_addrs() and pci_parse_of_flags
> > () ? Maybe create drivers/of/pci.c (or drivers/pci/of.c)? Or maybe they
> > are still too different?
> >
> > There is probably scope for more consolidation there.
>
> I agree, but I'll do those things in a separate patch. I'm making as
> few code changes as possible in this patch to ease review.
Yeah, that makes sense - it just struck me that I had seen that code
before elsewhere :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* mpc5200, reboots will idle
From: Jon Smirl @ 2009-08-21 15:23 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
I've been getting unexplained reboots. This one printed a dump. Does
it make sense to anyone?
The system was just sitting idle at a command prompt.
root@phyCORE:~ Bad trap at PC: c00098f0, SR: 1000, vector=100
Oops: Exception in kernel mode, sig: 5 [#1]
dspeak01
Modules linked in:
NIP: c00098f0 LR: c00098f0 CTR: c000f0bc
git REGS: c040fee0 TRAP: 0100 Not tainted (2.6.31-rc1-efika)
(actually rc6, commit 894ef820b10d77)
MSR: 00001000 <ME> CR: 24000028 XER: 20000000
TASK = c03dd3e8[0] 'swapper' THREAD: c040e000
<6>GPR00: 00000000 c040ff90 c03dd3e8 00800000 0090c000 00e00000
cba3e1bd 00049032
<6>GPR08: 00000001 c040e000 24000022 00000002 63694880 10068248
03fbc000 04079000
<6>GPR16: ff7fffbf ffaf7fbf fffeffff f8ffff3f 00003002 03f580b6
00000001 00000000
<6>GPR24: 00000000 03fba97c c0418000 c0410000 c0410000 c0417f2c
00000008 c040e03c
NIP [c00098f0] cpu_idle+0x94/0xd4
LR [c00098f0] cpu_idle+0x94/0xd4
Call Trace:
[c040ff90] [c000992c] cpu_idle+0xd0/0xd4 (unreliable)
[c040ffb0] [c0003e54] rest_init+0x5c/0x88
[c040ffc0] [c03b17c0] start_kernel+0x2a0/0x2b4
[c040fff0] [00003438] 0x3438
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX 7c0000a6 XXXXXXXX XXXXXXXX XXXXXXXX 70090004
XXXXXXXX XXXXXXXX XXXXXXXX 4e800421 XXXXXXXX XXXXXXXX XXXXXXXX 7c00f828
---[ end trace dafbcb51fa4ab255 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Call Trace:
[c040fcf0] [c00088cc] show_stack+0x4c/0x14c (unreliable)
[c040fd30] [c02bda4c] panic+0x8c/0x170
[c040fd80] [c002ab74] do_exit+0x60/0x594
[c040fdc0] [c0011848] kernel_bad_stack+0x0/0x4c
[c040fde0] [c00119e4] _exception+0x58/0x150
[c040fed0] [c0014050] ret_from_except_full+0x0/0x4c
--- Exception: 100 at cpu_idle+0x94/0xd4
LR = cpu_idle+0x94/0xd4
[c040ff90] [c000992c] cpu_idle+0xd0/0xd4 (unreliable)
[c040ffb0] [c0003e54] rest_init+0x5c/0x88
[c040ffc0] [c03b17c0] start_kernel+0x2a0/0x2b4
[c040fff0] [00003438] 0x3438
Rebooting in 180 seconds..
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: mpc5200, reboots will idle
From: Grant Likely @ 2009-08-21 16:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910908210823g1743ec7ei8bc80536afc7864f@mail.gmail.com>
On Fri, Aug 21, 2009 at 9:23 AM, Jon Smirl<jonsmirl@gmail.com> wrote:
> I've been getting unexplained reboots. This one printed a dump. Does
> it make sense to anyone?
> The system was just sitting idle at a command prompt.
No, I've not seen anything like that, and I don't see anything
interesting in the back trace. Data corruption in a device driver
perhaps?
I'll keep my eyes open if I see anything similar.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH V2] Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
From: Jon Smirl @ 2009-08-21 16:36 UTC (permalink / raw)
To: grant.likely, Linuxppc-dev
Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
Previous code had errors or used a constant. This versions computes
the right clock based on the xtal and register settings.
Adjusted from previous version to rebase onto current Linus tree.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/include/asm/mpc52xx.h | 2 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 26 ++++++++++++++++++++++++--
drivers/spi/mpc52xx_psc_spi.c | 8 +-------
sound/soc/fsl/mpc5200_psc_i2s.c | 12 +++++++++---
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
index cadd398..1ca8a0e 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -285,7 +285,7 @@ struct mpc52xx_rtc {
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
extern void mpc52xx_map_common_devices(void);
-extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
+extern int mpc52xx_set_psc_clkdiv(int psc_id, int freq);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
extern void mpc52xx_restart(char *cmd);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index a46bad0..8a19156 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -110,6 +110,8 @@ static struct of_device_id mpc52xx_cdm_ids[] __initdata = {
{}
};
+static u32 mpc52xx_fsystem; /* fsystem clock on mpc5200 */
+
/**
* mpc52xx_map_common_devices: iomap devices required by common code
*/
@@ -117,6 +119,7 @@ void __init
mpc52xx_map_common_devices(void)
{
struct device_node *np;
+ u32 val;
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
@@ -133,8 +136,16 @@ mpc52xx_map_common_devices(void)
/* Clock Distribution Module, used by PSC clock setting function */
np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
+ mpc52xx_fsystem = mpc5xxx_get_bus_frequency(np);
mpc52xx_cdm = of_iomap(np, 0);
of_node_put(np);
+
+ /* compute fsystem, it is either 4 or 8 times the bus freq */
+ val = in_be32(&mpc52xx_cdm->rstcfg);
+ if (val & (1 << 5))
+ mpc52xx_fsystem *= 8;
+ else
+ mpc52xx_fsystem *= 4;
}
/**
@@ -143,17 +154,28 @@ mpc52xx_map_common_devices(void)
* @psc_id: id of psc port; must be 1,2,3 or 6
* @clkdiv: clock divider value to put into CDM PSC register.
*/
-int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
+int mpc52xx_set_psc_clkdiv(int psc_id, int freq)
{
unsigned long flags;
u16 __iomem *reg;
u32 val;
- u32 mask;
+ u32 mask, clkdiv, err;
u32 mclken_div;
if (!mpc52xx_cdm)
return -ENODEV;
+ /* figure out the closest frequency the hardware can make */
+ clkdiv = mpc52xx_fsystem / freq;
+ err = mpc52xx_fsystem % freq;
+ if (err > freq / 2)
+ clkdiv++;
+ /* hardware is not very flexible, there will be significant error */
+ /* frequency error = fsystem / clkdiv - freq; */
+
+ /* hardware adds one to the divisor */
+ clkdiv -= 1;
+
mclken_div = 0x8000 | (clkdiv & 0x1FF);
switch (psc_id) {
case 1: reg = &mpc52xx_cdm->mclken_div_psc1; mask = 0x20; break;
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 1b74d5c..d000edc 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -32,7 +32,6 @@
struct mpc52xx_psc_spi {
/* fsl_spi_platform data */
void (*cs_control)(struct spi_device *spi, bool on);
- u32 sysclk;
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
@@ -312,12 +311,9 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
struct mpc52xx_psc __iomem *psc = mps->psc;
struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
- u32 mclken_div;
int ret = 0;
- /* default sysclk is 512MHz */
- mclken_div = (mps->sysclk ? mps->sysclk : 512000000) / MCLK;
- mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
+ mpc52xx_set_psc_clkdiv(psc_id, MCLK);
/* Reset the PSC into a known state */
out_8(&psc->command, MPC52xx_PSC_RST_RX);
@@ -382,12 +378,10 @@ static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
dev_warn(dev, "probe called without platform data, no "
"cs_control function will be called\n");
mps->cs_control = NULL;
- mps->sysclk = 0;
master->bus_num = bus_num;
master->num_chipselect = 255;
} else {
mps->cs_control = pdata->cs_control;
- mps->sysclk = pdata->sysclk;
master->bus_num = pdata->bus_num;
master->num_chipselect = pdata->max_chipselect;
}
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index ce8de90..2e347dd 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -14,6 +14,7 @@
#include <sound/pcm_params.h>
#include <sound/soc.h>
+#include <asm/mpc52xx.h>
#include <asm/mpc52xx_psc.h>
#include "mpc5200_psc_i2s.h"
@@ -90,9 +91,14 @@ static int psc_i2s_set_sysclk(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq, int dir)
{
struct psc_dma *psc_dma = cpu_dai->private_data;
- dev_dbg(psc_dma->dev, "psc_i2s_set_sysclk(cpu_dai=%p, dir=%i)\n",
- cpu_dai, dir);
- return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL;
+
+ dev_dbg(psc_dma->dev, "psc_i2s_set_sysclk(cpu_dai=%p, freq=%u, dir=%i)\n",
+ cpu_dai, freq, dir);
+
+ if (dir == SND_SOC_CLOCK_OUT)
+ return mpc52xx_set_psc_clkdiv(psc_dma->id + 1, freq);
+
+ return -EINVAL;
}
/**
^ permalink raw reply related
* Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
From: Sean MacLennan @ 2009-08-21 18:55 UTC (permalink / raw)
To: Feng Kan; +Cc: Feng Kan, linuxppc-dev, linux-mtd
In-Reply-To: <1250813957-1786-1-git-send-email-fkan@amcc.com>
On Thu, 20 Aug 2009 17:19:17 -0700
Feng Kan <fkan@amcc.com> wrote:
> Fix ECC Correction bug where the byte offset location were double
> fliped causing correction routine to toggle the wrong byte location
> in the ECC segment. The ndfc_calculate_ecc routine change the order
> of getting the ECC code.
It looks like another fix for this bug is to leave the current code
alone and turn off CONFIG_MTD_NAND_ECC_SMC.
This could be a better fix if this is the way u-boot currently works.
Has anybody verified if the current u-boot has the ECC problem?
Cheers,
Sean
^ permalink raw reply
* RE: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
From: Feng Kan @ 2009-08-21 18:56 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20090821145506.53275701@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
Yes, I have considered that. However, it would make the #define rather confusing
for the rest.
Cheers,
Feng
-----Original Message-----
From: Sean MacLennan [mailto:smaclennan@pikatech.com]
Sent: Fri 8/21/2009 11:55 AM
To: Feng Kan
Cc: linuxppc-dev@ozlabs.org; linux-mtd@lists.infradead.org; Feng Kan
Subject: Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
On Thu, 20 Aug 2009 17:19:17 -0700
Feng Kan <fkan@amcc.com> wrote:
> Fix ECC Correction bug where the byte offset location were double
> fliped causing correction routine to toggle the wrong byte location
> in the ECC segment. The ndfc_calculate_ecc routine change the order
> of getting the ECC code.
It looks like another fix for this bug is to leave the current code
alone and turn off CONFIG_MTD_NAND_ECC_SMC.
This could be a better fix if this is the way u-boot currently works.
Has anybody verified if the current u-boot has the ECC problem?
Cheers,
Sean
[-- Attachment #2: Type: text/html, Size: 1598 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
From: Victor Gallardo @ 2009-08-21 20:35 UTC (permalink / raw)
To: Sean MacLennan, Feng Kan; +Cc: linuxppc-dev, Feng Kan, linux-mtd
In-Reply-To: <20090821145506.53275701@lappy.seanm.ca>
Hi Sean=0A=0A> =0A> It looks like another fix for this bug is to leave the =
current code=0A> alone and turn off CONFIG_MTD_NAND_ECC_SMC.=0A=0AThis=A0wo=
uld fix the problem by hiding the issue. Fengs patch is=A0the correct way t=
o go.=0A=0ABest Regards,=0A=0AVictor Gallardo
^ permalink raw reply
* Having trouble using mtdparts kernel command line to repartition flash
From: Nathan French @ 2009-08-21 20:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
I've got a kilauea (PPC405EX) board that we've decided needs more room
in one of the flash partitions. So I took the existing command line
(which came from the dev kit):
Kernel command line: ramdisk_size=65536 root=/dev/ram rw
mtdparts=fc000000.nor_flash:2M(linux),20M(ramdisk),4M(jffs2),38272k(user),256k(env),384k(uboot) ip=10.2.3.28:10.1.0.65:10.0.0.1::kilauea:eth0:off panic=1 console=ttyS0,115200
And modified it like below (4M -> 8M, 38272k->34176k). We're not
currently using the user partition, so I just borrowed 4MB from it.
Kernel command line: ramdisk_size=65536 root=/dev/ram rw
mtdparts=fc000000.nor_flash:2M(linux),20M(ramdisk),8M(jffs2),34176k(user),256k(env),384k(uboot) ip=10.2.3.28:10.1.0.65:10.0.0.1::kilauea:eth0:off panic=1 console=ttyS0,115200
And I get the below error. I noticed that the device tree (FDT/DTB)
lists some partitions as well that don't exactly match up with the
original parameters, so I ignored that part of the FDT. Is this ok?
Does Linux ignore the partition information from the FDT when U-Boot
passes partition arguments?
Oh and... well why is the ram0 device complaining when I modify the
flash partitioning? I'm not expecting the 20M ramdisk portion to be
affected. Also I noticed that the device tree (DTS/DTB) does not
reflect the original partition scheme. Does it need to or is the device
tree ignored when using the mtdparts partitioning? I tried modifying it
to match but didn't seem to make a difference.
Am I missing something here?
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (24576 != 32768) 35815424
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 136k init
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
Warning: unable to open an initial console.
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
EXT2-fs error (device ram0): ext2_get_inode: unable to read inode block
- inode=12289, block=49155
attempt to access beyond end of device
ram0: rw=0, want=98312, limit=70000
...
Thanks,
Nathan French
^ permalink raw reply
* I2C_GPIO defined in device tree?
From: ST @ 2009-08-21 21:53 UTC (permalink / raw)
To: linuxppc-dev
Hi
Beeing new to the ppc platform (on xilinx xup fpga) i have a hard time finding
out the syntax
of the dts file. First i was tring to use the xilinx iic driver but the system
was always locking
up when using it. So i thought i am just simply switching to the i2c_gpio
driver. So i defined
another 2 port gpio and then got stuck in defining the pins to be used. So i
would be really glad
if someone could help me, telling me the proper format to define the GPIO pins
used by the i2c_gpio
driver.
Thanks
ST
PS: This is my current xilinx.dts file. "xps_gpio_iic" should provide the sda
sdl lines for the i2c_gpio driver:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex405", "xlnx,virtex";
model = "testing";
DDR_SDRAM: memory@0 {
device_type = "memory";
reg = < 0x0 0x10000000 >;
} ;
alias {
ethernet0 = &Ethernet_MAC;
serial0 = &RS232_Uart_1;
} ;
chosen {
bootargs = "console=ttyUL0 root=/dev/xsa2";
linux,stdout-path = "/plb@0/serial@84000000";
} ;
cpus {
#address-cells = <1>;
#cpus = <0x1>;
#size-cells = <0>;
ppc405_0: cpu@0 {
clock-frequency = <200000000>;
compatible = "PowerPC,405", "ibm,ppc405";
d-cache-line-size = <0x20>;
d-cache-size = <0x4000>;
dcr-access-method = "native";
dcr-controller ;
device_type = "cpu";
i-cache-line-size = <0x20>;
i-cache-size = <0x4000>;
model = "PowerPC,405";
reg = <0>;
timebase-frequency = <200000000>;
xlnx,dcr-resync = <0x0>;
xlnx,deterministic-mult = <0x0>;
xlnx,disable-operand-forwarding = <0x1>;
xlnx,fastest-plb-clock = "DPLB0";
xlnx,generate-plb-timespecs = <0x1>;
xlnx,mmu-enable = <0x1>;
} ;
} ;
plb0: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
ranges ;
DDR_SDRAM: mpmc@84800000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,mpmc-4.03.a";
reg = < 0x84800000 0x10000 >;
} ;
DIPSWs_4Bit: gpio@81480000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x81480000 0x10000 >;
xlnx,all-inputs = <0x1>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,family = "virtex2p";
xlnx,gpio-width = <0x4>;
xlnx,interrupt-present = <0x0>;
xlnx,is-bidir = <0x1>;
xlnx,is-bidir-2 = <0x1>;
xlnx,is-dual = <0x0>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;
Ethernet_MAC: ethernet@81000000 {
compatible
= "xlnx,xps-ethernetlite-2.00.b", "xlnx,xps-ethernetlite-1.00.a";
device_type = "network";
interrupt-parent = <&xps_intc_0>;
interrupts = < 1 0 >;
local-mac-address = [ 02 00 00 00 00 00 ];
reg = < 0x81000000 0x10000 >;
xlnx,duplex = <0x1>;
xlnx,family = "virtex2p";
xlnx,rx-ping-pong = <0x1>;
xlnx,tx-ping-pong = <0x1>;
} ;
LEDs_4Bit: gpio@81460000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x81460000 0x10000 >;
xlnx,all-inputs = <0x0>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,family = "virtex2p";
xlnx,gpio-width = <0x4>;
xlnx,interrupt-present = <0x0>;
xlnx,is-bidir = <0x0>;
xlnx,is-bidir-2 = <0x1>;
xlnx,is-dual = <0x0>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;
PushButtons_5Bit: gpio@81440000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x81440000 0x10000 >;
xlnx,all-inputs = <0x1>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,family = "virtex2p";
xlnx,gpio-width = <0x5>;
xlnx,interrupt-present = <0x0>;
xlnx,is-bidir = <0x1>;
xlnx,is-bidir-2 = <0x1>;
xlnx,is-dual = <0x0>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;
RS232_Uart_1: serial@84000000 {
clock-frequency = <100000000>;
compatible = "xlnx,xps-uartlite-1.00.a";
current-speed = <115200>;
device_type = "serial";
interrupt-parent = <&xps_intc_0>;
interrupts = < 2 0 >;
port-number = <0>;
reg = < 0x84000000 0x10000 >;
xlnx,baudrate = <0x1c200>;
xlnx,data-bits = <0x8>;
xlnx,family = "virtex2p";
xlnx,odd-parity = <0x0>;
xlnx,use-parity = <0x0>;
} ;
SysACE_CompactFlash: sysace@83600000 {
compatible = "xlnx,xps-sysace-1.00.a";
interrupt-parent = <&xps_intc_0>;
interrupts = < 0 2 >;
reg = < 0x83600000 0x10000 >;
xlnx,family = "virtex2p";
xlnx,mem-width = <0x10>;
} ;
left_lowspeed: gpio@81420000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x81420000 0x10000 >;
xlnx,all-inputs = <0x0>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,family = "virtex2p";
xlnx,gpio-width = <0x20>;
xlnx,interrupt-present = <0x0>;
xlnx,is-bidir = <0x1>;
xlnx,is-bidir-2 = <0x1>;
xlnx,is-dual = <0x0>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;
xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffc000 {
compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
reg = < 0xffffc000 0x4000 >;
xlnx,family = "virtex2p";
} ;
xps_gpio_iic: gpio@81400000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x81400000 0x10000 >;
xlnx,all-inputs = <0x0>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,family = "virtex2p";
xlnx,gpio-width = <0x2>;
xlnx,interrupt-present = <0x0>;
xlnx,is-bidir = <0x1>;
xlnx,is-bidir-2 = <0x1>;
xlnx,is-dual = <0x0>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;
xps_intc_0: interrupt-controller@81800000 {
#interrupt-cells = <0x2>;
compatible = "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg = < 0x81800000 0x10000 >;
xlnx,num-intr-inputs = <0x3>;
} ;
} ;
ppc405_0_dplb1: plb@1 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
ranges ;
} ;
} ;
^ permalink raw reply
* [PATCH] [JFFS2] Fix csize integer overflow issue due to truncation
From: Victor Gallardo @ 2009-08-21 22:43 UTC (permalink / raw)
To: linux-mtd; +Cc: Prodyut Hazarika, linuxppc-dev, Victor Gallardo, Feng Kan
This fixes a kernel BUG_ON(tn->size == 0) panic in check_node_data
due to integer overflow in read_dnone().
The code incorrectly assigns a uin32_t local variable (csize) to
uint16_t structure member in jffs2_tmp_dnode_info. This results
in an overflow when the local variable csize is greater than
65536 (0x10000)
This issue is seen when kernel PAGE_SIZE is 64K.
The following example illustrates the issue:
fs/jffs2/nodelist.h
struct jffs2_tmp_dnode_info
{
...
uint16_t csize;
...
};
fs/jffs2/readinode.c
static inline int read_dnode(...)
{
struct jffs2_tmp_dnode_info *tn;
uint32_t len, csize;
...
csize = je32_to_cpu(rd->csize);
...
tn->csize = csize; // <=== result truncated if > 0x10000
...
}
static int check_node_data(...)
{
...
BUG_ON(tn->csize == 0);
...
}
Signed-off-by: Victor Gallardo <vgallardo@amcc.com>
Acked-by: Prodyut Hazarika <phazarika@amcc.com>
Acked-by: Feng Kan <fkan@amcc.com>
---
fs/jffs2/nodelist.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
index 507ed6e..67f36c3 100644
--- a/fs/jffs2/nodelist.h
+++ b/fs/jffs2/nodelist.h
@@ -231,7 +231,7 @@ struct jffs2_tmp_dnode_info
uint32_t version;
uint32_t data_crc;
uint32_t partial_crc;
- uint16_t csize;
+ uint32_t csize;
uint16_t overlapped;
};
--
1.5.5
^ permalink raw reply related
* Re: [Patch 0/8] V4 Implement crashkernel=auto
From: Andrew Morton @ 2009-08-22 0:06 UTC (permalink / raw)
To: Amerigo Wang
Cc: fenghua.yu, nhorman, tony.luck, linux-ia64, amwang, linux-kernel,
linuxppc-dev, andi, ebiederm, mingo, bernhard.walle,
kamezawa.hiroyu
In-Reply-To: <20090821065637.4855.32234.sendpatchset@localhost.localdomain>
(cc linuxppc-dev@ozlabs.org)
On Fri, 21 Aug 2009 02:54:12 -0400
Amerigo Wang <amwang@redhat.com> wrote:
> This series of patch implements automatically reserved memory for crashkernel,
> by introducing a new boot option "crashkernel=auto". This idea is from Neil.
>
> In case of breaking user-space applications, it modifies this boot option after
> it decides how much memory should be reserved.
>
> On different arch, the threshold and reserved memory size is different. Please
> refer patch 8/8 which contains an update for the documentation.
>
> Patch 1/8 implements shrinking reserved memory at run-time, which is useful
> when more than enough memory is reserved automatically.
>
> Note: This patchset was only tested on x86_64 with differernt memory sizes.
I'd prefer that this change had been runtime tested on ia64 and powerpc
and has had some quality review from relevant developers of those
architectures.
Looking at the cc's, I'm not sure that the powerpc guys even know about
this work?
^ permalink raw reply
* [v2 PATCH 2/2] powerpc/405ex: support cuImage via included dtb
From: Tiejun Chen @ 2009-08-23 2:03 UTC (permalink / raw)
To: jwboyer, linuxppc-dev
In-Reply-To: <1250993024-29527-1-git-send-email-tiejun.chen@windriver.com>
To support cuImage, we need to initialize the required sections and
ensure that it is built.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/boot/Makefile | 2 +-
arch/powerpc/boot/cuboot-kilauea.c | 49 ++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-kilauea.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9ae7b7e..3e11611 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -75,7 +75,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
- cuboot-acadia.c cuboot-amigaone.c
+ cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
diff --git a/arch/powerpc/boot/cuboot-kilauea.c b/arch/powerpc/boot/cuboot-kilauea.c
new file mode 100644
index 0000000..b333346
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-kilauea.c
@@ -0,0 +1,49 @@
+/*
+ * Old U-boot compatibility for PPC405EX. This image is already included
+ * a dtb.
+ *
+ * Author: Tiejun Chen <tiejun.chen@windriver.com>
+ *
+ * Copyright (C) 2009 Wind River Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "io.h"
+#include "dcr.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+#define KILAUEA_SYS_EXT_SERIAL_CLOCK 11059200 /* ext. 11.059MHz clk */
+
+static bd_t bd;
+
+static void kilauea_fixups(void)
+{
+ unsigned long sysclk = 33333333;
+
+ ibm405ex_fixup_clocks(sysclk, KILAUEA_SYS_EXT_SERIAL_CLOCK);
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = kilauea_fixups;
+ platform_ops.exit = ibm40x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
--
1.5.6
^ 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