* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Geert Uytterhoeven @ 2009-02-24 18:01 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, Andrew Morton,
linux-ext4
In-Reply-To: <18850.31567.212454.514549@cargo.ozlabs.ibm.com>
On Mon, 23 Feb 2009, Paul Mackerras wrote:
> Andrew Morton writes:
> > It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > size);
> >
> > Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> > corrupted and this snuck through the defenses.
> >
> > I also wonder if there is enough info in that trace for a ppc person to
> > be able to determine whether the faulting address is in the source or
> > destination of the memcpy() (please)?
>
> It appears to have faulted on a load, implicating the source. The
> address being referenced (0xc00000003f380000) doesn't look
> outlandish. I wonder if this kernel has CONFIG_DEBUG_PAGEALLOC turned
> on, and what page size is selected?
I'm seeing a similar thing on PS3, but not in ext3. During early userspace
setup (udevd), it crashes accessing a 0xc00* address in:
| NIP setup+0x20/0x130
| LR copy_user_page+0x18/0x6c
| Call trace:
| do_wp_page+0x5b4/0x89c
| do_page_fault+0x3a8/0x58c
| handle_page_fault+0x20/0x5c
I have CONFIG_DEBUG_PAGEALLOC=y. If I disable it, the system boots fine.
If needed, I can probably bisect this tomorrow. It definitely didn't happen in
2.6.29-rc5.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-02-24 17:56 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Richard Zidlicky, rtc-linux, linux-parisc, David,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Linux/m68k, Woodhouse
In-Reply-To: <20090223160506.04e347c7@i1501.lan.towertech.it>
On Mon, 23 Feb 2009, Alessandro Zummo wrote:
> On Mon, 23 Feb 2009 13:34:49 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > my opinion on this kind of stuff is that I want to avoid the layering
> > > of implementations under the rtc subsystem. I'd rather prefer that each
> > > rtc device had its own driver.
> > >
> > > I've made error in the past, by accepting such kind of drivers, and
> > > would like to avoid that it happens again.
> >
> > So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k],
> > mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all
> > RTC code out of arch/ into seperate drivers under drivers/rtc/ instead?
>
> not all at once :)
>
> I'd start writing a working driver and then see how we should eventually
> adapt the rtc subsystem to cope with your needs.
OK, so here's a first example: rtc-ps3.
Note that this single patch adds 100+ lines of code, while my previous patch
series removed 500+ lines of code, while solving the autoloading problem for
several ppc and m68k platforms.
Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC
class drivers would add ca. 100+ lines of code for each individual driver.
>From 641412e4e638d00c8821c2d9b38e02727821a203 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Tue, 24 Feb 2009 14:04:20 +0100
Subject: [PATCH] Create a real RTC driver for PS3, called "rtc-ps3"
---
arch/powerpc/include/asm/ps3.h | 4 +
arch/powerpc/platforms/ps3/os-area.c | 2 +
arch/powerpc/platforms/ps3/platform.h | 2 -
arch/powerpc/platforms/ps3/setup.c | 2 -
arch/powerpc/platforms/ps3/time.c | 25 ++++----
drivers/rtc/Kconfig | 9 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-ps3.c | 106 +++++++++++++++++++++++++++++++++
8 files changed, 133 insertions(+), 18 deletions(-)
create mode 100644 drivers/rtc/rtc-ps3.c
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index b65446a..dee0480 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -500,6 +500,10 @@ u64 ps3_get_spe_id(void *arg);
/* mutex synchronizing GPU accesses and video mode changes */
extern struct mutex ps3_gpu_mutex;
+/* os area */
+u64 ps3_os_area_get_rtc_diff(void);
+void ps3_os_area_set_rtc_diff(u64 rtc_diff);
+
/* kernel debug routines */
int ps3_debug_setup_dabr(u64 address, unsigned int dabr_flags);
diff --git a/arch/powerpc/platforms/ps3/os-area.c b/arch/powerpc/platforms/ps3/os-area.c
index ccf0157..f1f2d47 100644
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -823,6 +823,7 @@ u64 ps3_os_area_get_rtc_diff(void)
{
return saved_params.rtc_diff;
}
+EXPORT_SYMBOL(ps3_os_area_get_rtc_diff);
/**
* ps3_os_area_set_rtc_diff - Set the rtc diff value.
@@ -838,6 +839,7 @@ void ps3_os_area_set_rtc_diff(u64 rtc_diff)
os_area_queue_work();
}
}
+EXPORT_SYMBOL(ps3_os_area_set_rtc_diff);
/**
* ps3_os_area_get_av_multi_out - Returns the default video mode.
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/ps3/platform.h
index 235c13e..136aa06 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -64,8 +64,6 @@ int ps3_set_rtc_time(struct rtc_time *time);
void __init ps3_os_area_save_params(void);
void __init ps3_os_area_init(void);
-u64 ps3_os_area_get_rtc_diff(void);
-void ps3_os_area_set_rtc_diff(u64 rtc_diff);
/* spu */
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index e2032c6..020ba1d 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -300,8 +300,6 @@ define_machine(ps3) {
.init_IRQ = ps3_init_IRQ,
.panic = ps3_panic,
.get_boot_time = ps3_get_boot_time,
- .set_rtc_time = ps3_set_rtc_time,
- .get_rtc_time = ps3_get_rtc_time,
.set_dabr = ps3_set_dabr,
.calibrate_decr = ps3_calibrate_decr,
.progress = ps3_progress,
diff --git a/arch/powerpc/platforms/ps3/time.c b/arch/powerpc/platforms/ps3/time.c
index d0daf7d..112397d 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -19,6 +19,7 @@
*/
#include <linux/kernel.h>
+#include <linux/platform_device.h>
#include <asm/rtc.h>
#include <asm/lv1call.h>
@@ -74,23 +75,19 @@ static u64 read_rtc(void)
return rtc_val;
}
-int ps3_set_rtc_time(struct rtc_time *tm)
+unsigned long __init ps3_get_boot_time(void)
{
- u64 now = mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
- tm->tm_hour, tm->tm_min, tm->tm_sec);
-
- ps3_os_area_set_rtc_diff(now - read_rtc());
- return 0;
+ return read_rtc() + ps3_os_area_get_rtc_diff();
}
-void ps3_get_rtc_time(struct rtc_time *tm)
-{
- to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
- tm->tm_year -= 1900;
- tm->tm_mon -= 1;
-}
+static struct platform_device rtc_ps3_dev = {
+ .name = "rtc-ps3",
+ .id = -1,
+};
-unsigned long __init ps3_get_boot_time(void)
+static int __init rtc_init(void)
{
- return read_rtc() + ps3_os_area_get_rtc_diff();
+ return platform_device_register(&rtc_ps3_dev);
}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..4b61288 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -736,4 +736,13 @@ config RTC_DRV_MV
This driver can also be built as a module. If so, the module
will be called rtc-mv.
+config RTC_DRV_PS3
+ tristate "PS3 RTC"
+ depends on PPC_PS3
+ help
+ If you say yes here you will get support for the RTC on PS3.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-ps3.
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..7fe627c 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -76,3 +76,4 @@ obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
obj-$(CONFIG_RTC_DRV_WM8350) += rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
obj-$(CONFIG_RTC_DRV_PCF50633) += rtc-pcf50633.o
+obj-$(CONFIG_RTC_DRV_PS3) += rtc-ps3.o
diff --git a/drivers/rtc/rtc-ps3.c b/drivers/rtc/rtc-ps3.c
new file mode 100644
index 0000000..84ae08c
--- /dev/null
+++ b/drivers/rtc/rtc-ps3.c
@@ -0,0 +1,106 @@
+/*
+ * PS3 RTC Driver
+ *
+ * Copyright 2009 Sony Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ * If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#include <asm/lv1call.h>
+#include <asm/ps3.h>
+
+
+static u64 read_rtc(void)
+{
+ int result;
+ u64 rtc_val;
+ u64 tb_val;
+
+ result = lv1_get_rtc(&rtc_val, &tb_val);
+ BUG_ON(result);
+
+ return rtc_val;
+}
+
+static int ps3_get_time(struct device *dev, struct rtc_time *tm)
+{
+ to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
+ tm->tm_year -= 1900;
+ tm->tm_mon -= 1;
+ return 0;
+}
+
+static int ps3_set_time(struct device *dev, struct rtc_time *tm)
+{
+ u64 now = mktime(tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ ps3_os_area_set_rtc_diff(now - read_rtc());
+ return 0;
+}
+
+static const struct rtc_class_ops ps3_rtc_ops = {
+ .read_time = ps3_get_time,
+ .set_time = ps3_set_time,
+};
+
+static int __devinit ps3_rtc_probe(struct platform_device *dev)
+{
+ struct rtc_device *rtc;
+
+ rtc = rtc_device_register("rtc-ps3", &dev->dev, &ps3_rtc_ops,
+ THIS_MODULE);
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
+ platform_set_drvdata(dev, rtc);
+ return 0;
+}
+
+static int __devexit ps3_rtc_remove(struct platform_device *dev)
+{
+ rtc_device_unregister(platform_get_drvdata(dev));
+ return 0;
+}
+
+static struct platform_driver ps3_rtc_driver = {
+ .driver = {
+ .name = "rtc-ps3",
+ .owner = THIS_MODULE,
+ },
+ .probe = ps3_rtc_probe,
+ .remove = __devexit_p(ps3_rtc_remove),
+};
+
+static int __init ps3_rtc_init(void)
+{
+ return platform_driver_register(&ps3_rtc_driver);
+}
+
+static void __exit ps3_rtc_fini(void)
+{
+ platform_driver_unregister(&ps3_rtc_driver);
+}
+
+module_init(ps3_rtc_init);
+module_exit(ps3_rtc_fini);
+
+MODULE_AUTHOR("Sony Corporation");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ps3 RTC driver");
+MODULE_ALIAS("platform:rtc-ps3");
--
1.6.0.4
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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 related
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Kyle McMartin @ 2009-02-24 17:48 UTC (permalink / raw)
To: Sam Ravnborg
Cc: kyle, Kyle McMartin, linux-kernel, linuxppc-dev, aoliva, roland
In-Reply-To: <20090224084034.GA11847@uranus.ravnborg.org>
On Tue, Feb 24, 2009 at 09:40:34AM +0100, Sam Ravnborg wrote:
> x86 has a specific ".section .eh_frame,"a",@progbits" in vdso32/int80.S as one example.
>
> Have you analyzed all these hits?
>
These aren't effected by the patch. All the occurances of it inside the
kernel are explicitly written for the vdso/vsyscall functionality (which
needs it, since it's mapped into a userspace task, and you obviously
might be running a debugger on it.) The other hit in x86_64 is just a
discard section of the linker script.
regards, Kyle
^ permalink raw reply
* Re: Problem with decrementer interrupt
From: sumedh tirodkar @ 2009-02-24 17:32 UTC (permalink / raw)
To: sjoyeau; +Cc: linuxppc-dev
In-Reply-To: <d2b9ccd90902240353p51e2e9e7med67612a6ec19271@mail.gmail.com>
I found out the problem...it was somewhere in my code...actually the
link register was getting over-written...
Thanks for help...
Regards,
Sumedh
On Tue, Feb 24, 2009 at 5:23 PM, sumedh tirodkar
<sumedhtirodkar@gmail.com> wrote:
> The reason that i m using bla is that i am writing the interrupt
> handler from dec_start: to dec_end:....
> then i am relocating this code to its corresponding vector
> location(0x900)...As this relocated code is gonna be executed on
> occurrence of interrupt, i cant use bl instruction...i have to go for
> bla...
> The C code is getting executed for sure...hav checked this using some
> debug message...But the return from that function is not
> happening...somehow the link register is not getting properly
> loaded...dont knw wat is the reason behind this...
>
> Regards,
> Sumedh
>
> On Tue, Feb 24, 2009 at 1:24 PM, sjoyeau@wanadoo.fr <sjoyeau@wanadoo.fr> =
wrote:
>> Sumedh,
>>
>> I've just noticed you are using the "bla" instruction, which use absolut=
e
>> target address: are you sure the C code gets even be executed ?
>> I don't know how the compiler successfully assemble your code because th=
e
>> binary is supposed to be position independant code (PIC): you should rat=
her
>> use "bl" instruction (relative branch).
>>
>> --
>> sj
>>
>> 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>>>
>>> I have initialised to stack pointer(r1) properly...actually...i went
>>> thru the object dump...bt when i juz use
>>>
>>> =A0bla <function_name_handler>
>>>
>>> the link register is not getting pushed on to the stack in the prolog
>>> of that function...so the stack is basically not coming into the
>>> picture...
>>> @IRQ originator, that doesn't seem to be a problem...
>>>
>>> The only thing that i am able to think of is that when i do a "bla",
>>> the return address is not getting stored in link register...and i m
>>> not able to figure out why...
>>>
>>> Regards,
>>> Sumedh
>>>
>>> On Mon, Feb 23, 2009 at 11:03 PM, sjoyeau@wanadoo.fr <sjoyeau@wanadoo.f=
r>
>>> wrote:
>>> > Hi Sumedh,
>>> >
>>> > You may check the context in which your CPU in running the C code fro=
m
>>> > interrupt context (ie stack pointer (r1), kernel locks disabling
>>> > rescheduling etc..) and double check the IRQ originator (the
>>> > decrementer) is
>>> > acknowlegded somewhere your handler before enabling back interrupts,
>>> > else
>>> > your handler gets fired.
>>> >
>>> > --
>>> > sj
>>> >
>>> > 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>>> >>
>>> >> Alright...I am trying to develop a system of my own..
>>> >> Consider that i am not using any linux kernel...I m writing some
>>> >> program right from scratch.........
>>> >> The major steps that i have taken are...
>>> >>
>>> >> 1. Started with a assembly file...
>>> >> 2. Have relocated the interrupt handlers to there respective
>>> >> positions...The interrupt handlers are written in assembly language.=
..
>>> >> 3. Initialised Decrementer register to get an interrupt after some
>>> >> interval...
>>> >> 4. Jump to some function using
>>> >>
>>> >> =A0 =A0bl <function_name_main>
>>> >>
>>> >> =A0 =A0function_name_main which will have a infinite while loop..
>>> >> This works fine i.e. the interrupts(decrementer interrupt to be more
>>> >> specific) work fine...I have initialised serial port to get the
>>> >> output...
>>> >>
>>> >> Now, the problem that i am facing....
>>> >>
>>> >> If in interrupt handler of the decrementer, i make a call to some C
>>> >> function in some other C file...using the follwing statement...
>>> >>
>>> >> Dec_handler: =A0/* I have relocated this to interrupt vector address=
of
>>> >> decrementer interrupt*/
>>> >> =A0 =A0 /*code to print using serial port*/
>>> >> =A0 =A0 bla <function_name_handler> /*code to call some function in =
C
>>> >> file*/
>>> >> =A0 =A0 /*code to print using serial port---but i m never able to se=
e this
>>> >> output*/
>>> >> =A0 =A0 RFI
>>> >>
>>> >> This starts creating a problem...somehow we dont return to this code
>>> >> after the end of the function_name_handler...
>>> >> Consider the following code for the function_name_handler:
>>> >> void function_name_handler(void)
>>> >> {
>>> >> =A0 /*Some action*/
>>> >> }
>>> >>
>>> >> So, if its possible for anyone to help me with this...please reply..=
.
>>> >>
>>> >> Regards,
>>> >> Sumedh
>>> >>
>>> >>
>>> >> On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner <mgessner@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
>>> >> > <sumedhtirodkar@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC.=
..
>>> >> >
>>> >> > What I said earlier was: You need to tell people what cpu you're
>>> >> > using,
>>> >> > what
>>> >> > linux kernel, etc etc etc.
>>> >> >
>>> >> > Fine, we know the CPU. =A0What kernel are you using? =A0Is it anci=
ent?
>>> >> >
>>> >> > I doubt the information below is going to be useful...
>>> >> >
>>> >> >>
>>> >> >> I am using
>>> >> >>
>>> >> >> bla <function_name>
>>> >> >>
>>> >> >> from the assembly code to call the function in C file...This i am
>>> >> >> doing from interrupt handler of the decrementer...
>>> >> >> If any more details are required, please let me know...
>>> >> >
>>> >> >
>>> >> _______________________________________________
>>> >> Linuxppc-dev mailing list
>>> >> Linuxppc-dev@ozlabs.org
>>> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>> >
>>> >
>>> >
>>> > --
>>> > ------------------
>>> > Sylvain JOYEAU
>>> > Freelance Engineer
>>> > Software RT-OS R&D
>>> > sylvain.joyeau@gmail.com
>>> > T=E9l: +33-(0)667 477 052
>>> > "A good idea is one side of the coin. The other side is the practical
>>> > usefulness". J. Liedke.
>>> >
>>>
>>>
>>
>>
>>
>> --
>> ------------------
>> Sylvain JOYEAU
>> Freelance Engineer
>> Software RT-OS R&D
>> sylvain.joyeau@gmail.com
>> T=E9l: +33-(0)667 477 052
>> "A good idea is one side of the coin. The other side is the practical
>> usefulness". J. Liedke.
>>
>
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-24 16:58 UTC (permalink / raw)
To: Haruki Dai-R35557, linuxppc-dev; +Cc: Gala Kumar-B11780
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD3302B1EB2E@az33exm24.fsl.freescale.net>
Dai,
> I am not so sure about your PHY, but if you access to PHY while
packet
> transmission through MDIO bus, the packet might be corrupted. Do you
> have "phy_interrupt" in the /proc/interrupts? What is your dmesg
around
> the eTSEC look like (there is phy driver info surrounded).
With some printks, I did confirm that the kernel is polling the phy
every second or so. So, I modified the routine which reads the phy
status to hardcode the link state, speed, and duplex without actually
performing any reads and the driver still bug checks with a truncated
packet. I also dropped a printk in phy_read() and phy_write(), but
neither function is getting called with the hard-coded link information.
In gfar_clean_tx_ring() I printed out the tx descriptor data length
field when I detected that the descriptor had the TR bit set. For 5 bug
checks in a row, the data length field was set to 1960 (which would
definitely cause the packet truncation). I then went back into
gfar_start_xmit() and added some additional BUG_ON() checks of the data
length field before the descriptor is handed off to the TSEC and none of
them fire. I am wondering if somehow the descriptor is getting
corrupted, perhaps by some code with an errant pointer.
Scott=20
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Eric Cottrell @ 2009-02-24 16:56 UTC (permalink / raw)
To: nvbolhuis; +Cc: linuxppc-dev
In-Reply-To: <49A4205B.30207@aimvalley.nl>
Hello,
It never booted properly out of the box.
I raised the issue with the Distributor but have not heard back yet.
73 Eric
----- Start Original Message -----
Sent: Tue, 24 Feb 2009 17:29:15 +0100
From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
To: Eric Cottrell <wb1hbu@runbox.com>
Subject: Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
> Hi Eric,
>=20
> So it never ever booted properly ?
>=20
> Hmm, it certainly looks like your distributor (or whoever you got the MPC=
8313E-RDB
> from) lend it out and got a messed up board back. Or maybe they messed it=
up
> themselfes.
>=20
> Go complain and send it back.
>=20
> indeed, rev 2.x is better (much less TSEC bugs).
>=20
> ---
> N. van Bolhuis.
>=20
>=20
>=20
> Eric Cottrell wrote:
> > Hello,
> >=20
> > Thanks for the help. I will look into that. It is confusing as the la=
test ltib appears not to have the aliases. This is my first venture into E=
mbedded Linux as our existing PowerPC products use PSOS. Most of my Linux =
experience is on the Intel PC platform.
> >=20
> > Yes, the 1.3.3 version was what was shipped with the board. The rootfs=
and kernel appear to be older. So I suspect someone upgraded the uBoot an=
d ran into trouble.
> >=20
> > I am comparing this with the Rev B board we also got. I hope to return=
the Rev A4 and make the boards all Rev B because it has a later processor.=
The Rev B boards have 1.3.0 so it should need the aliases as well. Looki=
ng in the uBoot changelogs there are some nice additions and fixes for this=
board so I will look to dig more into uBoot and upgrade it. I hate to stu=
mble out of the box.
> >=20
> > 73 Eric
> >=20
>=20
----- End Original Message -----
^ permalink raw reply
* Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Norbert van Bolhuis @ 2009-02-24 16:29 UTC (permalink / raw)
To: Eric Cottrell; +Cc: linuxppc-dev
In-Reply-To: <E1LbyOG-0000uL-Hf@garm.runbox.com>
Hi Eric,
So it never ever booted properly ?
Hmm, it certainly looks like your distributor (or whoever you got the MPC8313E-RDB
from) lend it out and got a messed up board back. Or maybe they messed it up
themselfes.
Go complain and send it back.
indeed, rev 2.x is better (much less TSEC bugs).
---
N. van Bolhuis.
Eric Cottrell wrote:
> Hello,
>
> Thanks for the help. I will look into that. It is confusing as the latest ltib appears not to have the aliases. This is my first venture into Embedded Linux as our existing PowerPC products use PSOS. Most of my Linux experience is on the Intel PC platform.
>
> Yes, the 1.3.3 version was what was shipped with the board. The rootfs and kernel appear to be older. So I suspect someone upgraded the uBoot and ran into trouble.
>
> I am comparing this with the Rev B board we also got. I hope to return the Rev A4 and make the boards all Rev B because it has a later processor. The Rev B boards have 1.3.0 so it should need the aliases as well. Looking in the uBoot changelogs there are some nice additions and fixes for this board so I will look to dig more into uBoot and upgrade it. I hate to stumble out of the box.
>
> 73 Eric
>
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Jan Kara @ 2009-02-24 16:14 UTC (permalink / raw)
To: Sachin P. Sant
Cc: Mel Gorman, linuxppc-dev, Andrew Morton, linux-ext4, linux-kernel
In-Reply-To: <49A27EE8.5030700@in.ibm.com>
> Andrew Morton wrote:
> >hm, I wonder what could have caused that - we haven't altered
> >fs/ext3/xattr.c in ages.
> >
> >What is the most recent kernel version you know of which didn't do
> >this? Bear in mind that this crash might be triggered by the
> >current contents of the filesystem, so if possible, please test
> >some other kernel versions on that disk.
> >
> I am trying to boot a vanilla kernel on this machine for the first
> time. Haven't tried any other kernels. Will give it a try.
>
> >It looks like we died in ext3_xattr_block_get():
> >
> > memcpy(buffer, bh->b_data + le16_to_cpu(entry->e_value_offs),
> > size);
> >
> >Perhaps entry->e_value_offs is no good. I wonder if the filesystem is
> >corrupted and this snuck through the defenses.
> >
> >I also wonder if there is enough info in that trace for a ppc person to
> >be able to determine whether the faulting address is in the source or
> >destination of the memcpy() (please)?
> >
> Some more information if this could be of any help.
>
> 0:mon> di 0xc000000000039574
> c000000000039574 e9240008 ld r9,8(r4)
> c000000000039578 409d0010 ble cr7,c000000000039588 #
> .memcpy+0x88/0x244
> c00000000003957c 79290002 rotldi r9,r9,32
> c000000000039580 91230000 stw r9,0(r3)
> c000000000039584 38630004 addi r3,r3,4
> c000000000039588 409e0010 bne cr7,c000000000039598 #
> .memcpy+0x98/0x244
> c00000000003958c 79298000 rotldi r9,r9,16
> c000000000039590 b1230000 sth r9,0(r3)
> c000000000039594 38630002 addi r3,r3,2
> c000000000039598 409f000c bns cr7,c0000000000395a4 #
> .memcpy+0xa4/0x244
> c00000000003959c 79294000 rotldi r9,r9,8
> c0000000000395a0 99230000 stb r9,0(r3)
> c0000000000395a4 e8610030 ld r3,48(r1)
> c0000000000395a8 4e800020 blr
> c0000000000395ac 78a6e8c2 rldicl r6,r5,61,3
> c0000000000395b0 38a5fff0 addi r5,r5,-16
> 0:mon> r
> R00 = 000000000000e40f R16 = 00000000100edbc8
> R01 = c00000003e59b3e0 R17 = 00000000100b0000
> R02 = c0000000009c2110 R18 = 0000000000000005
> R03 = c000000044bc90e0 R19 = 00000000fff0d7a8
> R04 = c000000039cffff4 R20 = 00000000fff0d708
> R05 = 0000000000000003 R21 = 00000000000000ff
> R06 = 0000000000000000 R22 = 0000000000000006
> R07 = 0000000000000001 R23 = c00000000079ab49
> R08 = 723a7573725f743a R24 = c0000000372fe2a8
> R09 = 3a6f626a6563745f R25 = c000000044bc90c8
> R10 = c00000003b250968 R26 = c0000000372fe240
> R11 = c000000000039500 R27 = c0000000372fe3b0
> R12 = d00000000244c590 R28 = c0000000372c5280
> R13 = c000000000a53480 R29 = 000000000000001b
> R14 = 00000000100d0000 R30 = d0000000024654d0
> R15 = 0000000000000000 R31 = ffffffffffffffde
> pc = c000000000039574 .memcpy+0x74/0x244
> lr = d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3]
> msr = 8000000000009032 cr = 4400844b
> ctr = 0000000000000000 xer = 0000000000000001 trap = 300
> dar = c000000039d00000 dsisr = 40000000
> 0:mon>
Yes, this makes me even more suspitious that memcpy() on powerpc could
be at fault. The instruction (ld r9,8(r4)) is loading last 8 bytes to copy,
but in fact it should load only 3 bytes in our case because remaining 5
bytes are not in the range we specified and thus larger load can cause
page fault...
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Jan Kara @ 2009-02-24 15:51 UTC (permalink / raw)
To: Sachin P. Sant
Cc: Jan Kara, Mark Nelson, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-ext4
In-Reply-To: <49A395ED.5030607@in.ibm.com>
Hello,
On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> Jan Kara wrote:
>> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
>> somehow got beyond end of the page referenced by bh->b_data. So it means
>> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
>> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
>> particular checks whether e_value_offs + e_value_size isn't greater than
>> bh->b_size. So I see no way how memcpy can get beyond end of the page.
>> Sachin, is the problem reproducible? If yes, can you send us contents
>>
> Yes, i am able to recreate this problem easily. As i had mentioned if the
> earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> without any problem.
>
>> of the page just before the faulting address (i.e., for current fault it
>> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can
>> remember powerpc monitor could dump it.
>>
> Here is the page dump. This time it crashed while accessing address
> 0xc00000002d670000.
Thanks for the dump.
> Unable to handle kernel paging request for data at address 0xc0000
> 0002d670000
> Faulting instruction address: 0xc000000000039574
> cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0]
> pc: c000000000039574: .memcpy+0x74/0x244
> lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4
> sp: c00000004288b330
> msr: 8000000000009032
>
> 1:mon> d 0xc00000002d660000
> ............................... <SNIP> ...............................
>
> c00000002d66efd0 0000000000000000 0000000000000000 |................|
> c00000002d66efe0 0000000000000000 0000000000000000 |................|
> c00000002d66eff0 0000000000000000 0000000000000000 |................|
> c00000002d66f000 000002ea00040000 01000000e200d20a |................|
> c00000002d66f010 0000000000000000 0000000000000000 |................|
> c00000002d66f020 0706e40f00000000 1b000000e200d20a |................|
> c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........|
> c00000002d66f040 0000000000000000 0000000000000000 |................|
> c00000002d66f050 0000000000000000 0000000000000000 |................|
> c00000002d66f060 0000000000000000 0000000000000000 |................|
>
> ............................... <SNIP> ...............................
>
> c00000002d66ff60 0000000000000000 0000000000000000 |................|
> c00000002d66ff70 0000000000000000 0000000000000000 |................|
> c00000002d66ff80 0000000000000000 0000000000000000 |................|
> c00000002d66ff90 0000000000000000 0000000000000000 |................|
> c00000002d66ffa0 0000000000000000 0000000000000000 |................|
> c00000002d66ffb0 0000000000000000 0000000000000000 |................|
> c00000002d66ffc0 0000000000000000 0000000000000000 |................|
> c00000002d66ffd0 0000000000000000 0000000000000000 |................|
> c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj|
> c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..|
> c00000002d670000 **************** **************** | |
> 1:mon> r
> R00 = 000000000000e40f R16 = 000000000000005d
> R01 = c00000004288b330 R17 = 0000000000000000
> R02 = c0000000009f59b8 R18 = 00000000fffbfe9e
> R03 = c000000044aa34a0 R19 = 0000000010042638
> R04 = c00000002d66fff4 R20 = 0000000010041610
> R05 = 0000000000000003 R21 = 00000000000000ff
> R06 = 0000000000000000 R22 = 0000000000000006
> R07 = 0000000000000001 R23 = c0000000007d27c1
> R08 = 723a7573725f743a R24 = c00000002c0cd758
> R09 = 3a6f626a6563745f R25 = c000000044aa3488
> R10 = c00000000017b43c R26 = c00000002c0cd6f0
> R11 = c00000002d66f020 R27 = c00000002c0cd860
> R12 = d0000000023c14b0 R28 = c00000002c0b0840
> R13 = c000000000a93680 R29 = 000000000000001b
> R14 = 00000000000041ed R30 = c0000000009880b0
> R15 = 0000000010040000 R31 = ffffffffffffffde
> pc = c000000000039574 .memcpy+0x74/0x244
> lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4
> msr = 8000000000009032 cr = 4400044b
> ctr = 0000000000000000 xer = 0000000020000001 trap = 300
> dar = c00000002d670000 dsisr = 40000000
> 1:mon> zr
>
>> BTW, I suppose you use 4KB blocksize on the filesystem, right?
>>
> Yes.
>
> dumpe2fs /dev/sda3 | grep -i "block size" dumpe2fs 1.39 (29-May-2006)
> Block size: 4096
OK. The xattr block causing oops is completely correct. To me it seems
more like some problem in powerpc memcpy() (I saw there went some changes
into in in the end of December) - we call it to copy 27 bytes from
address 0xc00000002d66ffe4 (which is one byte before end of the page).
Could some of the powerpc guys have a look whether this could be the case?
I'm not quite fluent in the powerpc assembly so it would take me ages ;).
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: Please pull 'next' branch
From: Geert Uytterhoeven @ 2009-02-24 14:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.0902241531500.544@vixen.sonytel.be>
On Tue, 24 Feb 2009, Geert Uytterhoeven wrote:
> On Tue, 24 Feb 2009, Josh Boyer wrote:
> > Please pull the next branch of the 4xx tree. It has a few small commits
>
> Any chance we can get the fix for PCI on e.g. Sequoia in?
> This is a regression from 2.6.28.
BTW, I don't see the patch on
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Eric Cottrell @ 2009-02-24 14:36 UTC (permalink / raw)
To: nvbolhuis; +Cc: linuxppc-dev
In-Reply-To: <49A3EBFF.4030906@aimvalley.nl>
Hello,
Thanks for the help. I will look into that. It is confusing as the latest=
ltib appears not to have the aliases. This is my first venture into Embed=
ded Linux as our existing PowerPC products use PSOS. Most of my Linux expe=
rience is on the Intel PC platform.
Yes, the 1.3.3 version was what was shipped with the board. The rootfs and=
kernel appear to be older. So I suspect someone upgraded the uBoot and ra=
n into trouble.
I am comparing this with the Rev B board we also got. I hope to return the=
Rev A4 and make the boards all Rev B because it has a later processor. Th=
e Rev B boards have 1.3.0 so it should need the aliases as well. Looking i=
n the uBoot changelogs there are some nice additions and fixes for this boa=
rd so I will look to dig more into uBoot and upgrade it. I hate to stumble=
out of the box.
73 Eric
----- Start Original Message -----
Sent: Tue, 24 Feb 2009 13:45:51 +0100
From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
To: Eric Cottrell <wb1hbu@runbox.com>
Subject: Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
> Hi Eric,
>=20
> I have the same board and same problem. It's just an incompatibility betw=
een the
> DTB and u-boot.
> Recent u-boots (and without a doubt also your u-boot 1.3.3) expect aliases
> in the DTB, these ones I guess:
>=20
> .
> .
> aliases {
> ethernet0 =3D &enet0;
> ethernet1 =3D &enet1;
> serial0 =3D &serial0;
> serial1 =3D &serial1;
> pci0 =3D &pci0;
> };
> .
> .
>=20
> Not being able to find alias "serial0" (in the DTB) causes this problem.
> see u-boot/common/fdt_support.c:fdt_fixup_stdout
>=20
> Older u-boots don't expect them. My REV A4 board was shipped with
> "U-Boot 1.1.6 (Aug 24 2007 - 13:10:12) MPC83XX" (which obviously not expe=
cts the aliases).
>=20
> If I flash a new/custom u-boot (U-Boot 2008.10) the problem occurs.
>=20
> I assume Freescale ships their REV A4 boards with a u-boot not expecting =
the
> aliases.
> I assume your u-boot 1.3.3 is not the one the board was shipped with,
> are are you saying it is ?
>=20
> ---
> N. van Bolhuis.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Eric Cottrell wrote:
> > Hello,
> >=20
> > This is getting frustrating and I am beginning to think someone messed =
this board up and returned it. I would think it would boot up the default =
flash image out of the box with very little trouble.
> >=20
> > Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instruc=
tions, S4 all off and S3 all on.
> > Uboot comes up but I can not boot either the default images in the flas=
h or images I built with ltib and tftped. I did not touch the flash. I ge=
t WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR: /cho=
sen node create failed - must RESET the board to recover. The board resets.
> >=20
> > A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 200=
8 - 13:41:53) MPC83XX and some environment variables are different. I do n=
ot have the BOOTCMD variable but entered it manually.
> >=20
> > I tried searching for on a solution but it is confusing because if alia=
ses are needed why does the default dtb in the flash omit them?
> >=20
> > This is what happens:
> >=20
> > U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
> >=20
> > Reset Status:
> >=20
> > CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
> > Board: Freescale MPC8313ERDB
> > I2C: ready
> > DRAM: 128 MB
> > FLASH: 8 MB
> > In: serial
> > Out: serial
> > Err: serial
> > Net: TSEC0, TSEC1 [PRIME]
> > =3D> bootm fe100000 fe300000 fe700000
> > ## Booting kernel from Legacy Image at fe100000 ...
> > Image Name: Linux-2.6.20
> > Created: 2007-08-24 14:59:01 UTC
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1722821 Bytes =3D 1.6 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > ## Flattened Device Tree blob at fe700000
> > Booting using the fdt blob at 0xfe700000
> > ## Loading init Ramdisk from Legacy Image at fe300000 ...
> > Image Name: uboot ext2 ramdisk rootfs
> > Created: 2007-08-24 15:01:41 UTC
> > Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> > Data Size: 2831355 Bytes =3D 2.7 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Loading Device Tree to 007fd000, end 007fffff ... OK
> > WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
> > ERROR: /chosen node create failed - must RESET the board to recover.
> > Resetting the board.
> >=20
> >=20
> > U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
> >=20
> > Reset Status: Software Hard, External/Internal Soft, External/Internal =
Hard
> >=20
> > CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
> > Board: Freescale MPC8313ERDB
> > I2C: ready
> > DRAM: 128 MB
> > FLASH: 8 MB
> > In: serial
> > Out: serial
> > Err: serial
> > Net: TSEC0, TSEC1 [PRIME]
> > =3D>=20
> >=20
> > 73 Eric
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >=20
>=20
>=20
----- End Original Message -----
^ permalink raw reply
* Re: Please pull 'next' branch
From: Geert Uytterhoeven @ 2009-02-24 14:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090224140800.GA2323@yoda.jdub.homelinux.org>
On Tue, 24 Feb 2009, Josh Boyer wrote:
> Please pull the next branch of the 4xx tree. It has a few small commits
Any chance we can get the fix for PCI on e.g. Sequoia in?
This is a regression from 2.6.28.
> for 2.6.30, as well as the 256K page size patch for 44x.
(Oops, this is for 2.6.30. What about 2.6.29?)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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
* Please pull 'next' branch
From: Josh Boyer @ 2009-02-24 14:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
Please pull the next branch of the 4xx tree. It has a few small commits
for 2.6.30, as well as the 256K page size patch for 44x.
josh
The following changes since commit 6071ed0487c6ea8dcfadd9844b9b90944cd9de1e:
Michael Ellerman (1):
powerpc/pseries: Return the number of MSIs we could allocate
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Benjamin Herrenschmidt (2):
powerpc/4xx: Add missing USB and i2c devices to Canyonlands
powerpc/4xx: Enable PCI domains on 4xx
Madhulika Madishetty (1):
AMCC PPC 460SX redwood SoC platform initial framework
Yuri Tikhonov (1):
powerpc/44x: Support for 256KB PAGE_SIZE
arch/powerpc/Kconfig | 27 +
arch/powerpc/boot/dts/canyonlands.dts | 28 +
arch/powerpc/boot/dts/redwood.dts | 244 +++++
arch/powerpc/configs/44x/canyonlands_defconfig | 266 +++++-
arch/powerpc/configs/44x/redwood_defconfig | 1176 ++++++++++++++++++++++++
arch/powerpc/include/asm/highmem.h | 10 +-
arch/powerpc/include/asm/mmu-44x.h | 2 +
arch/powerpc/include/asm/page.h | 6 +-
arch/powerpc/include/asm/page_32.h | 4 +
arch/powerpc/include/asm/thread_info.h | 4 +-
arch/powerpc/kernel/cpu_setup_44x.S | 1 +
arch/powerpc/kernel/cputable.c | 14 +
arch/powerpc/kernel/head_booke.h | 11 +-
arch/powerpc/platforms/44x/Kconfig | 19 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +
16 files changed, 1796 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/redwood.dts
create mode 100644 arch/powerpc/configs/44x/redwood_defconfig
^ permalink raw reply
* Re: Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
From: Norbert van Bolhuis @ 2009-02-24 12:45 UTC (permalink / raw)
To: Eric Cottrell; +Cc: linuxppc-dev
In-Reply-To: <E1LbNft-0007z6-Pf@garm.runbox.com>
Hi Eric,
I have the same board and same problem. It's just an incompatibility between the
DTB and u-boot.
Recent u-boots (and without a doubt also your u-boot 1.3.3) expect aliases
in the DTB, these ones I guess:
.
.
aliases {
ethernet0 = &enet0;
ethernet1 = &enet1;
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
};
.
.
Not being able to find alias "serial0" (in the DTB) causes this problem.
see u-boot/common/fdt_support.c:fdt_fixup_stdout
Older u-boots don't expect them. My REV A4 board was shipped with
"U-Boot 1.1.6 (Aug 24 2007 - 13:10:12) MPC83XX" (which obviously not expects the aliases).
If I flash a new/custom u-boot (U-Boot 2008.10) the problem occurs.
I assume Freescale ships their REV A4 boards with a u-boot not expecting the
aliases.
I assume your u-boot 1.3.3 is not the one the board was shipped with,
are are you saying it is ?
---
N. van Bolhuis.
Eric Cottrell wrote:
> Hello,
>
> This is getting frustrating and I am beginning to think someone messed this board up and returned it. I would think it would boot up the default flash image out of the box with very little trouble.
>
> Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instructions, S4 all off and S3 all on.
> Uboot comes up but I can not boot either the default images in the flash or images I built with ltib and tftped. I did not touch the flash. I get WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR: /chosen node create failed - must RESET the board to recover. The board resets.
>
> A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 2008 - 13:41:53) MPC83XX and some environment variables are different. I do not have the BOOTCMD variable but entered it manually.
>
> I tried searching for on a solution but it is confusing because if aliases are needed why does the default dtb in the flash omit them?
>
> This is what happens:
>
> U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
>
> Reset Status:
>
> CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
> Board: Freescale MPC8313ERDB
> I2C: ready
> DRAM: 128 MB
> FLASH: 8 MB
> In: serial
> Out: serial
> Err: serial
> Net: TSEC0, TSEC1 [PRIME]
> => bootm fe100000 fe300000 fe700000
> ## Booting kernel from Legacy Image at fe100000 ...
> Image Name: Linux-2.6.20
> Created: 2007-08-24 14:59:01 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1722821 Bytes = 1.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Flattened Device Tree blob at fe700000
> Booting using the fdt blob at 0xfe700000
> ## Loading init Ramdisk from Legacy Image at fe300000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Created: 2007-08-24 15:01:41 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 2831355 Bytes = 2.7 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Device Tree to 007fd000, end 007fffff ... OK
> WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
> ERROR: /chosen node create failed - must RESET the board to recover.
> Resetting the board.
>
>
> U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
>
> Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
>
> CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
> Board: Freescale MPC8313ERDB
> I2C: ready
> DRAM: 128 MB
> FLASH: 8 MB
> In: serial
> Out: serial
> Err: serial
> Net: TSEC0, TSEC1 [PRIME]
> =>
>
> 73 Eric
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: G4 oprofile: variable number of counters
From: Octavian Purdila @ 2009-02-24 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1233724934.16867.290.camel@pasglop>
>> static int oprofile_running;
>> -static u32 mmcr0_val, mmcr1_val, mmcr2_val;
>> +static u32 mmcr0_val, mmcr1_val, mmcr2_val, ctrs;
>
>This may be static but it's still a global scope as far as kernel
>symbols are concerned. Care to give it a slightly better name ? num_pmcs
>would probably be already more telling.
Sure. v2 will follow, with s/ctrs/num_pmcs/.
Thanks,
tavi
^ permalink raw reply
* [PATCH v2 2/2] powerpc: oprofile: enable support for ppc750 processors
From: Octavian Purdila @ 2009-02-24 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Octavian Purdila
In-Reply-To: <1233724934.16867.290.camel@pasglop>
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
arch/powerpc/kernel/cputable.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..4e20cfb 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -726,6 +726,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = "ppc750",
+ .oprofile_cpu_type = "ppc/7450",
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750FX rev 2.0 must disable HID0[DPM] */
.pvr_mask = 0xffffffff,
@@ -741,6 +743,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = "ppc750",
+ .oprofile_cpu_type = "ppc/7450",
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750FX (All revs except 2.0) */
.pvr_mask = 0xffff0000,
@@ -756,6 +760,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750fx,
.machine_check = machine_check_generic,
.platform = "ppc750",
+ .oprofile_cpu_type = "ppc/7450",
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750GX */
.pvr_mask = 0xffff0000,
--
1.5.6.5
^ permalink raw reply related
* [PATCH v2 1/2] powerpc: G4 oprofile: variable number of counters
From: Octavian Purdila @ 2009-02-24 12:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Octavian Purdila
In-Reply-To: <1233724934.16867.290.camel@pasglop>
For ppc750 processors which use 4 performance counters instead of the
6 G4 uses but otherwise is compatible with G4.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
arch/powerpc/oprofile/op_model_7450.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/oprofile/op_model_7450.c b/arch/powerpc/oprofile/op_model_7450.c
index cc599eb..f8d36f9 100644
--- a/arch/powerpc/oprofile/op_model_7450.c
+++ b/arch/powerpc/oprofile/op_model_7450.c
@@ -29,7 +29,7 @@
static unsigned long reset_value[OP_MAX_COUNTER];
static int oprofile_running;
-static u32 mmcr0_val, mmcr1_val, mmcr2_val;
+static u32 mmcr0_val, mmcr1_val, mmcr2_val, num_pmcs;
#define MMCR0_PMC1_SHIFT 6
#define MMCR0_PMC2_SHIFT 0
@@ -88,13 +88,12 @@ static int fsl7450_cpu_setup(struct op_counter_config *ctr)
mtspr(SPRN_MMCR0, mmcr0_val);
mtspr(SPRN_MMCR1, mmcr1_val);
- mtspr(SPRN_MMCR2, mmcr2_val);
+ if (num_pmcs > 4)
+ mtspr(SPRN_MMCR2, mmcr2_val);
return 0;
}
-#define NUM_CTRS 6
-
/* Configures the global settings for the countes on all CPUs. */
static int fsl7450_reg_setup(struct op_counter_config *ctr,
struct op_system_config *sys,
@@ -102,12 +101,13 @@ static int fsl7450_reg_setup(struct op_counter_config *ctr,
{
int i;
+ num_pmcs = num_ctrs;
/* Our counters count up, and "count" refers to
* how much before the next interrupt, and we interrupt
* on overflow. So we calculate the starting value
* which will give us "count" until overflow.
* Then we set the events on the enabled counters */
- for (i = 0; i < NUM_CTRS; ++i)
+ for (i = 0; i < num_ctrs; ++i)
reset_value[i] = 0x80000000UL - ctr[i].count;
/* Set events for Counters 1 & 2 */
@@ -123,9 +123,10 @@ static int fsl7450_reg_setup(struct op_counter_config *ctr,
/* Set events for Counters 3-6 */
mmcr1_val = mmcr1_event3(ctr[2].event)
- | mmcr1_event4(ctr[3].event)
- | mmcr1_event5(ctr[4].event)
- | mmcr1_event6(ctr[5].event);
+ | mmcr1_event4(ctr[3].event);
+ if (num_ctrs > 4)
+ mmcr1_val |= mmcr1_event5(ctr[4].event)
+ | mmcr1_event6(ctr[5].event);
mmcr2_val = 0;
@@ -139,7 +140,7 @@ static int fsl7450_start(struct op_counter_config *ctr)
mtmsr(mfmsr() | MSR_PMM);
- for (i = 0; i < NUM_CTRS; ++i) {
+ for (i = 0; i < num_pmcs; ++i) {
if (ctr[i].enabled)
classic_ctr_write(i, reset_value[i]);
else
@@ -184,7 +185,7 @@ static void fsl7450_handle_interrupt(struct pt_regs *regs,
pc = mfspr(SPRN_SIAR);
is_kernel = is_kernel_addr(pc);
- for (i = 0; i < NUM_CTRS; ++i) {
+ for (i = 0; i < num_pmcs; ++i) {
val = classic_ctr_read(i);
if (val < 0) {
if (oprofile_running && ctr[i].enabled) {
--
1.5.6.5
^ permalink raw reply related
* Re: Problem with decrementer interrupt
From: sumedh tirodkar @ 2009-02-24 11:53 UTC (permalink / raw)
To: sjoyeau; +Cc: linuxppc-dev
In-Reply-To: <d194b8ce0902232354m513bb164m57800d4f31ca2e0a@mail.gmail.com>
The reason that i m using bla is that i am writing the interrupt
handler from dec_start: to dec_end:....
then i am relocating this code to its corresponding vector
location(0x900)...As this relocated code is gonna be executed on
occurrence of interrupt, i cant use bl instruction...i have to go for
bla...
The C code is getting executed for sure...hav checked this using some
debug message...But the return from that function is not
happening...somehow the link register is not getting properly
loaded...dont knw wat is the reason behind this...
Regards,
Sumedh
On Tue, Feb 24, 2009 at 1:24 PM, sjoyeau@wanadoo.fr <sjoyeau@wanadoo.fr> wr=
ote:
> Sumedh,
>
> I've just noticed you are using the "bla" instruction, which use absolute
> target address: are you sure the C code gets even be executed ?
> I don't know how the compiler successfully assemble your code because the
> binary is supposed to be position independant code (PIC): you should rath=
er
> use "bl" instruction (relative branch).
>
> --
> sj
>
> 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>>
>> I have initialised to stack pointer(r1) properly...actually...i went
>> thru the object dump...bt when i juz use
>>
>> bla <function_name_handler>
>>
>> the link register is not getting pushed on to the stack in the prolog
>> of that function...so the stack is basically not coming into the
>> picture...
>> @IRQ originator, that doesn't seem to be a problem...
>>
>> The only thing that i am able to think of is that when i do a "bla",
>> the return address is not getting stored in link register...and i m
>> not able to figure out why...
>>
>> Regards,
>> Sumedh
>>
>> On Mon, Feb 23, 2009 at 11:03 PM, sjoyeau@wanadoo.fr <sjoyeau@wanadoo.fr=
>
>> wrote:
>> > Hi Sumedh,
>> >
>> > You may check the context in which your CPU in running the C code from
>> > interrupt context (ie stack pointer (r1), kernel locks disabling
>> > rescheduling etc..) and double check the IRQ originator (the
>> > decrementer) is
>> > acknowlegded somewhere your handler before enabling back interrupts,
>> > else
>> > your handler gets fired.
>> >
>> > --
>> > sj
>> >
>> > 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>> >>
>> >> Alright...I am trying to develop a system of my own..
>> >> Consider that i am not using any linux kernel...I m writing some
>> >> program right from scratch.........
>> >> The major steps that i have taken are...
>> >>
>> >> 1. Started with a assembly file...
>> >> 2. Have relocated the interrupt handlers to there respective
>> >> positions...The interrupt handlers are written in assembly language..=
.
>> >> 3. Initialised Decrementer register to get an interrupt after some
>> >> interval...
>> >> 4. Jump to some function using
>> >>
>> >> bl <function_name_main>
>> >>
>> >> function_name_main which will have a infinite while loop..
>> >> This works fine i.e. the interrupts(decrementer interrupt to be more
>> >> specific) work fine...I have initialised serial port to get the
>> >> output...
>> >>
>> >> Now, the problem that i am facing....
>> >>
>> >> If in interrupt handler of the decrementer, i make a call to some C
>> >> function in some other C file...using the follwing statement...
>> >>
>> >> Dec_handler: /* I have relocated this to interrupt vector address of
>> >> decrementer interrupt*/
>> >> /*code to print using serial port*/
>> >> bla <function_name_handler> /*code to call some function in C
>> >> file*/
>> >> /*code to print using serial port---but i m never able to see thi=
s
>> >> output*/
>> >> RFI
>> >>
>> >> This starts creating a problem...somehow we dont return to this code
>> >> after the end of the function_name_handler...
>> >> Consider the following code for the function_name_handler:
>> >> void function_name_handler(void)
>> >> {
>> >> /*Some action*/
>> >> }
>> >>
>> >> So, if its possible for anyone to help me with this...please reply...
>> >>
>> >> Regards,
>> >> Sumedh
>> >>
>> >>
>> >> On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner <mgessner@gmail.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
>> >> > <sumedhtirodkar@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC..=
.
>> >> >
>> >> > What I said earlier was: You need to tell people what cpu you're
>> >> > using,
>> >> > what
>> >> > linux kernel, etc etc etc.
>> >> >
>> >> > Fine, we know the CPU. What kernel are you using? Is it ancient?
>> >> >
>> >> > I doubt the information below is going to be useful...
>> >> >
>> >> >>
>> >> >> I am using
>> >> >>
>> >> >> bla <function_name>
>> >> >>
>> >> >> from the assembly code to call the function in C file...This i am
>> >> >> doing from interrupt handler of the decrementer...
>> >> >> If any more details are required, please let me know...
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Linuxppc-dev mailing list
>> >> Linuxppc-dev@ozlabs.org
>> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >
>> >
>> >
>> > --
>> > ------------------
>> > Sylvain JOYEAU
>> > Freelance Engineer
>> > Software RT-OS R&D
>> > sylvain.joyeau@gmail.com
>> > T=E9l: +33-(0)667 477 052
>> > "A good idea is one side of the coin. The other side is the practical
>> > usefulness". J. Liedke.
>> >
>>
>>
>
>
>
> --
> ------------------
> Sylvain JOYEAU
> Freelance Engineer
> Software RT-OS R&D
> sylvain.joyeau@gmail.com
> T=E9l: +33-(0)667 477 052
> "A good idea is one side of the coin. The other side is the practical
> usefulness". J. Liedke.
>
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Alexandre Oliva @ 2009-02-24 11:25 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Kyle McMartin, linux-kernel, roland, kyle
In-Reply-To: <20090224084034.GA11847@uranus.ravnborg.org>
On Feb 24, 2009, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
>> From: Kyle McMartin <kyle@redhat.com>
>>
>> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
>> sections, which are, for the kernel, fairly pointless. Additionally, on
>> ppc64 this generates a relocation format which the kernel module loader
>> does not currently support (R_PPC64_REL32.)
>>
>> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
>> .eh_frame section from being generated.
>>
>> These seem to be used for unwinding, but it doesn't look like we
>> currently use them anywhere. (In fact, we explicitly dump them in the
>> x86_64 linker script.)
> A grep for "eh_frame" shows too many hits in the kernel to convince
> me this is true.
I don't know whether .eh_frame is used for anything in the kernel. It
doesn't matter, as far as the patch is concerned.
What the flag above does is to restore the .eh_frame behavior from GCC
4.3, in which, when compiling with -g, rather than using .cfi assembler
directives, GCC emitted .debug_frame and (when needed) .eh_frame itself.
The "when needed" is key. The assembler doesn't know which of these to
emit, so it emits both in response to .cfi directives. It's also
possible that the assembler selects more efficient relocations than GCC.
Regardless, it's precisely the presence of new relocations in .eh_frame
that caused the reported problem.
This flag will just restore the .eh_frame that you had with earlier
versions of GCC, so that you don't have to cope with the enlarged and
possibly modified one that the combination of new GCC and new binutils
generates when compiling with -g. It will thus still serve whatever
purpose it did before.
I hope this helps,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Sam Ravnborg @ 2009-02-24 8:40 UTC (permalink / raw)
To: Kyle McMartin; +Cc: linuxppc-dev, aoliva, linux-kernel, roland, kyle
In-Reply-To: <20090224065112.GA6690@bombadil.infradead.org>
On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
> From: Kyle McMartin <kyle@redhat.com>
>
> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
> sections, which are, for the kernel, fairly pointless. Additionally, on
> ppc64 this generates a relocation format which the kernel module loader
> does not currently support (R_PPC64_REL32.)
>
> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
> .eh_frame section from being generated.
>
> These seem to be used for unwinding, but it doesn't look like we
> currently use them anywhere. (In fact, we explicitly dump them in the
> x86_64 linker script.)
A grep for "eh_frame" shows too many hits in the kernel to convince
me this is true.
arch/m32r/kernel/vmlinux.lds.S: from .altinstructions and .eh_frame */
arch/mn10300/kernel/vmlinux.lds.S: from .altinstructions and .eh_frame */
arch/parisc/kernel/vmlinux.lds.S: * from .altinstructions and .eh_frame
arch/powerpc/kernel/vdso32/sigtramp.S: .section .eh_frame,"a",@progbits
arch/powerpc/kernel/vdso32/vdso32.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
arch/powerpc/kernel/vdso32/vdso32.lds.S: .eh_frame : { KEEP (*(.eh_frame)) }:text
arch/powerpc/kernel/vdso32/vdso32.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/powerpc/kernel/vdso64/sigtramp.S: .section .eh_frame,"a",@progbits
arch/powerpc/kernel/vdso64/vdso64.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
arch/powerpc/kernel/vdso64/vdso64.lds.S: .eh_frame : { KEEP (*(.eh_frame)) }:text
arch/powerpc/kernel/vdso64/vdso64.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/s390/kernel/vdso32/vdso32.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
arch/s390/kernel/vdso32/vdso32.lds.S: .eh_frame : { KEEP (*(.eh_frame)) } :text
arch/s390/kernel/vdso32/vdso32.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/s390/kernel/vdso64/vdso64.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
arch/s390/kernel/vdso64/vdso64.lds.S: .eh_frame : { KEEP (*(.eh_frame)) } :text
arch/s390/kernel/vdso64/vdso64.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/sh/kernel/vsyscall/vsyscall-sigreturn.S: .section .eh_frame,"a",@progbits
arch/sh/kernel/vsyscall/vsyscall-trapa.S: * fill out .eh_frame -- PFM. */
arch/sh/kernel/vsyscall/vsyscall-trapa.S: .section .eh_frame,"a",@progbits
arch/sh/kernel/vsyscall/vsyscall.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr ) } :text :eh_frame_hdr
arch/sh/kernel/vsyscall/vsyscall.lds.S: .eh_frame : {
arch/sh/kernel/vsyscall/vsyscall.lds.S: KEEP (*(.eh_frame))
arch/sh/kernel/vsyscall/vsyscall.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/um/include/asm/common.lds.S: from .altinstructions and .eh_frame */
arch/um/kernel/dyn.lds.S: .eh_frame : { KEEP (*(.eh_frame)) }
arch/x86/kernel/vmlinux_32.lds.S: from .altinstructions and .eh_frame */
arch/x86/kernel/vmlinux_64.lds.S: from .altinstructions and .eh_frame */
arch/x86/kernel/vmlinux_64.lds.S: *(.eh_frame)
arch/x86/vdso/vdso-layout.lds.S: .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
arch/x86/vdso/vdso-layout.lds.S: .eh_frame : { KEEP (*(.eh_frame)) } :text
arch/x86/vdso/vdso-layout.lds.S: eh_frame_hdr PT_GNU_EH_FRAME;
arch/x86/vdso/vdso32/int80.S: .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/int80.S:VDSO32_vsyscall_eh_frame_size = 0x40
arch/x86/vdso/vdso32/int80.S: .space VDSO32_vsyscall_eh_frame_size-(.LENDFDEDLSI-.LSTARTFRAMEDLSI), 0
arch/x86/vdso/vdso32/sigreturn.S: .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/syscall.S: .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/syscall.S:VDSO32_vsyscall_eh_frame_size = 0x40
arch/x86/vdso/vdso32/syscall.S: .space VDSO32_vsyscall_eh_frame_size-(.LENDFDE1-.LSTARTFRAME), 0
arch/x86/vdso/vdso32/sysenter.S: .section .eh_frame,"a",@progbits
arch/x86/vdso/vdso32/sysenter.S: * Emit a symbol with the size of this .eh_frame data,
arch/x86/vdso/vdso32/sysenter.S:VDSO32_vsyscall_eh_frame_size = (.LENDFDEDLSI-.LSTARTFRAMEDLSI)
x86 has a specific ".section .eh_frame,"a",@progbits" in vdso32/int80.S as one example.
Have you analyzed all these hits?
Sam
^ permalink raw reply
* Re: Problem with decrementer interrupt
From: sjoyeau @ 2009-02-24 7:54 UTC (permalink / raw)
To: sumedh tirodkar; +Cc: linuxppc-dev
In-Reply-To: <d2b9ccd90902231002m41062108kb36c9ba4e7b70aa4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4867 bytes --]
Sumedh,
I've just noticed you are using the "bla" instruction, which use absolute
target address: are you sure the C code gets even be executed ?
I don't know how the compiler successfully assemble your code because the
binary is supposed to be position independant code (PIC): you should rather
use "bl" instruction (relative branch).
--
sj
2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>
> I have initialised to stack pointer(r1) properly...actually...i went
> thru the object dump...bt when i juz use
>
> bla <function_name_handler>
>
> the link register is not getting pushed on to the stack in the prolog
> of that function...so the stack is basically not coming into the
> picture...
> @IRQ originator, that doesn't seem to be a problem...
>
> The only thing that i am able to think of is that when i do a "bla",
> the return address is not getting stored in link register...and i m
> not able to figure out why...
>
> Regards,
> Sumedh
>
> On Mon, Feb 23, 2009 at 11:03 PM, sjoyeau@wanadoo.fr <sjoyeau@wanadoo.fr>
> wrote:
> > Hi Sumedh,
> >
> > You may check the context in which your CPU in running the C code from
> > interrupt context (ie stack pointer (r1), kernel locks disabling
> > rescheduling etc..) and double check the IRQ originator (the decrementer)
> is
> > acknowlegded somewhere your handler before enabling back interrupts, else
> > your handler gets fired.
> >
> > --
> > sj
> >
> > 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
> >>
> >> Alright...I am trying to develop a system of my own..
> >> Consider that i am not using any linux kernel...I m writing some
> >> program right from scratch.........
> >> The major steps that i have taken are...
> >>
> >> 1. Started with a assembly file...
> >> 2. Have relocated the interrupt handlers to there respective
> >> positions...The interrupt handlers are written in assembly language...
> >> 3. Initialised Decrementer register to get an interrupt after some
> >> interval...
> >> 4. Jump to some function using
> >>
> >> bl <function_name_main>
> >>
> >> function_name_main which will have a infinite while loop..
> >> This works fine i.e. the interrupts(decrementer interrupt to be more
> >> specific) work fine...I have initialised serial port to get the
> >> output...
> >>
> >> Now, the problem that i am facing....
> >>
> >> If in interrupt handler of the decrementer, i make a call to some C
> >> function in some other C file...using the follwing statement...
> >>
> >> Dec_handler: /* I have relocated this to interrupt vector address of
> >> decrementer interrupt*/
> >> /*code to print using serial port*/
> >> bla <function_name_handler> /*code to call some function in C file*/
> >> /*code to print using serial port---but i m never able to see this
> >> output*/
> >> RFI
> >>
> >> This starts creating a problem...somehow we dont return to this code
> >> after the end of the function_name_handler...
> >> Consider the following code for the function_name_handler:
> >> void function_name_handler(void)
> >> {
> >> /*Some action*/
> >> }
> >>
> >> So, if its possible for anyone to help me with this...please reply...
> >>
> >> Regards,
> >> Sumedh
> >>
> >>
> >> On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner <mgessner@gmail.com>
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
> >> > <sumedhtirodkar@gmail.com>
> >> > wrote:
> >> >>
> >> >> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
> >> >
> >> > What I said earlier was: You need to tell people what cpu you're
> using,
> >> > what
> >> > linux kernel, etc etc etc.
> >> >
> >> > Fine, we know the CPU. What kernel are you using? Is it ancient?
> >> >
> >> > I doubt the information below is going to be useful...
> >> >
> >> >>
> >> >> I am using
> >> >>
> >> >> bla <function_name>
> >> >>
> >> >> from the assembly code to call the function in C file...This i am
> >> >> doing from interrupt handler of the decrementer...
> >> >> If any more details are required, please let me know...
> >> >
> >> >
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> >
> > --
> > ------------------
> > Sylvain JOYEAU
> > Freelance Engineer
> > Software RT-OS R&D
> > sylvain.joyeau@gmail.com
> > Tél: +33-(0)667 477 052
> > "A good idea is one side of the coin. The other side is the practical
> > usefulness". J. Liedke.
> >
>
>
>
--
------------------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&D
sylvain.joyeau@gmail.com
Tél: +33-(0)667 477 052
"A good idea is one side of the coin. The other side is the practical
usefulness". J. Liedke.
[-- Attachment #2: Type: text/html, Size: 6691 bytes --]
^ permalink raw reply
* [PATCH] powerpc/spufs: Initialize ctx->stats.tstamp correctly
From: Jeremy Kerr @ 2009-02-24 7:44 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, cbe-oss-dev
From: Arnd Bergmann <arnd@arndb.de>
spuctx_switch_state() warns if ktime goes backwards, but it
sometimes compares an uninitialized value, which showed that
the data was unreliable when we actually saw the warning.
Initialize it to the current time in order to get correct data.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
Ben - another spufs patch for 2.6.30
---
arch/powerpc/platforms/cell/spufs/context.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/cell/spufs/context.c b/arch/powerpc/platforms/cell/spufs/context.c
index 6653ddb..db5398c 100644
--- a/arch/powerpc/platforms/cell/spufs/context.c
+++ b/arch/powerpc/platforms/cell/spufs/context.c
@@ -35,6 +35,8 @@ atomic_t nr_spu_contexts = ATOMIC_INIT(0);
struct spu_context *alloc_spu_context(struct spu_gang *gang)
{
struct spu_context *ctx;
+ struct timespec ts;
+
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
if (!ctx)
goto out;
@@ -64,6 +66,8 @@ struct spu_context *alloc_spu_context(struct spu_gang *gang)
__spu_update_sched_info(ctx);
spu_set_timeslice(ctx);
ctx->stats.util_state = SPU_UTIL_IDLE_LOADED;
+ ktime_get_ts(&ts);
+ ctx->stats.tstamp = timespec_to_ns(&ts);
atomic_inc(&nr_spu_contexts);
goto out;
^ permalink raw reply related
* [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4
From: Kyle McMartin @ 2009-02-24 6:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kyle, aoliva, linux-kernel, roland
From: Kyle McMartin <kyle@redhat.com>
On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
sections, which are, for the kernel, fairly pointless. Additionally, on
ppc64 this generates a relocation format which the kernel module loader
does not currently support (R_PPC64_REL32.)
Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
.eh_frame section from being generated.
These seem to be used for unwinding, but it doesn't look like we
currently use them anywhere. (In fact, we explicitly dump them in the
x86_64 linker script.)
If these .eh_frame sections are eventually used, adding a per-arch
CONFIG_WANT_UNWIND check would be trivial.
(This was reported against Fedora, which appears to be the only distro
doing any building against gcc-4.4 at present: RH bz#486545.)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Cc: roland@redhat.com
Cc: aoliva@redhat.com
---
diff --git a/Makefile b/Makefile
index df6ce3e..d66a512 100644
--- a/Makefile
+++ b/Makefile
@@ -566,6 +566,11 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
# disable pointer signed / unsigned warnings in gcc 4.0
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
+# gcc-4.4 defaults to generating .eh_frame sections, but we aren't
+# interested in those currently. additionally, it causes issues on some
+# architectures.
+KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
+
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
# But warn user when we do so
warn-assign = \
^ permalink raw reply related
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Sachin P. Sant @ 2009-02-24 6:38 UTC (permalink / raw)
To: Jan Kara
Cc: Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev, Paul Mackerras,
Andrew Morton, linux-ext4
In-Reply-To: <20090223155116.GB5764@atrey.karlin.mff.cuni.cz>
Jan Kara wrote:
> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> somehow got beyond end of the page referenced by bh->b_data. So it means
> that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> particular checks whether e_value_offs + e_value_size isn't greater than
> bh->b_size. So I see no way how memcpy can get beyond end of the page.
> Sachin, is the problem reproducible? If yes, can you send us contents
>
Yes, i am able to recreate this problem easily. As i had mentioned if the
earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
without any problem.
> of the page just before the faulting address (i.e., for current fault it
> would be 0xc00000003f370000-0xc00000003f37ffff). As far as I can
> remember powerpc monitor could dump it.
>
Here is the page dump. This time it crashed while accessing address
0xc00000002d670000.
Unable to handle kernel paging request for data at address 0xc0000
0002d670000
Faulting instruction address: 0xc000000000039574
cpu 0x1: Vector: 300 (Data Access) at [c00000004288b0b0]
pc: c000000000039574: .memcpy+0x74/0x244
lr: c0000000001b497c: .ext3_xattr_get+0x288/0x2f4
sp: c00000004288b330
msr: 8000000000009032
1:mon> d 0xc00000002d660000
............................... <SNIP> ...............................
c00000002d66efd0 0000000000000000 0000000000000000 |................|
c00000002d66efe0 0000000000000000 0000000000000000 |................|
c00000002d66eff0 0000000000000000 0000000000000000 |................|
c00000002d66f000 000002ea00040000 01000000e200d20a |................|
c00000002d66f010 0000000000000000 0000000000000000 |................|
c00000002d66f020 0706e40f00000000 1b000000e200d20a |................|
c00000002d66f030 73656c696e757800 0000000000000000 |selinux.........|
c00000002d66f040 0000000000000000 0000000000000000 |................|
c00000002d66f050 0000000000000000 0000000000000000 |................|
c00000002d66f060 0000000000000000 0000000000000000 |................|
............................... <SNIP> ...............................
c00000002d66ff60 0000000000000000 0000000000000000 |................|
c00000002d66ff70 0000000000000000 0000000000000000 |................|
c00000002d66ff80 0000000000000000 0000000000000000 |................|
c00000002d66ff90 0000000000000000 0000000000000000 |................|
c00000002d66ffa0 0000000000000000 0000000000000000 |................|
c00000002d66ffb0 0000000000000000 0000000000000000 |................|
c00000002d66ffc0 0000000000000000 0000000000000000 |................|
c00000002d66ffd0 0000000000000000 0000000000000000 |................|
c00000002d66ffe0 0000000073797374 656d5f753a6f626a |....system_u:obj|
c00000002d66fff0 6563745f723a7573 725f743a73300000 |ect_r:usr_t:s0..|
c00000002d670000 **************** **************** | |
1:mon> r
R00 = 000000000000e40f R16 = 000000000000005d
R01 = c00000004288b330 R17 = 0000000000000000
R02 = c0000000009f59b8 R18 = 00000000fffbfe9e
R03 = c000000044aa34a0 R19 = 0000000010042638
R04 = c00000002d66fff4 R20 = 0000000010041610
R05 = 0000000000000003 R21 = 00000000000000ff
R06 = 0000000000000000 R22 = 0000000000000006
R07 = 0000000000000001 R23 = c0000000007d27c1
R08 = 723a7573725f743a R24 = c00000002c0cd758
R09 = 3a6f626a6563745f R25 = c000000044aa3488
R10 = c00000000017b43c R26 = c00000002c0cd6f0
R11 = c00000002d66f020 R27 = c00000002c0cd860
R12 = d0000000023c14b0 R28 = c00000002c0b0840
R13 = c000000000a93680 R29 = 000000000000001b
R14 = 00000000000041ed R30 = c0000000009880b0
R15 = 0000000010040000 R31 = ffffffffffffffde
pc = c000000000039574 .memcpy+0x74/0x244
lr = c0000000001b497c .ext3_xattr_get+0x288/0x2f4
msr = 8000000000009032 cr = 4400044b
ctr = 0000000000000000 xer = 0000000020000001 trap = 300
dar = c00000002d670000 dsisr = 40000000
1:mon> zr
> BTW, I suppose you use 4KB blocksize on the filesystem, right?
>
Yes.
dumpe2fs /dev/sda3 | grep -i "block size"
dumpe2fs 1.39 (29-May-2006)
Block size: 4096
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Interrupt sense value in device tree
From: Vijay Nikam @ 2009-02-24 6:23 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Hello,
I created a device node for gpio-controller for evaluation board
mpc83313erdb. I created the dtb and loaded on target.
But in dts at interrupts = <74 0x2> I set sense as Edge (sense== 2:
Edge, high-to-low change), when I load the driver module and checked
the entry in /proc/interrupts it shows the sense as 'Level' i.e. 8
(sense == 8: Level, low assertion) as follows;
74: 1 IPIC Level gpio
Following is gpio-controller device tree node;
gpio-controller@c00 {
#gpio-cells = <2>;
compatible = "fsl,mpc8313-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x100>;
interrupts = <74 0x2>;
interrupt-parent = <&ipic>;
gpio-controller;
};
Could anyone please tell what could be the reason ? ? ? Am I missing
something ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
##################### Start ############################
cat /proc/interrupts
CPU0
16: 162 IPIC Level serial
19: 43 IPIC Level i2c-mpc
20: 1 IPIC Level i2c-mpc
22: 2 IPIC Edge phy_interrupt
32: 0 IPIC Level enet_error
33: 765 IPIC Level enet_rx
34: 3 IPIC Level enet_tx
35: 0 IPIC Level enet_error
36: 0 IPIC Level enet_rx
37: 15 IPIC Level enet_tx
38: 0 IPIC Edge ehci_hcd:usb1
72: 0 IPIC Level gtm timer
74: 1 IPIC Level gpio
77: 51451 IPIC Level fsl-elbc
80: 0 IPIC Level pmc
BAD: 0
###################### END ############################
^ 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