* RE: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-23 21:55 UTC (permalink / raw)
To: Dan Malek, Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <31d4fa0af2a0d11f029d675ae5bd331c@embeddededge.com>
> On Apr 23, 2005, at 8:42 AM, Marcelo Tosatti wrote:
>
> >> Does CONFIG_PIN_TLB make a difference?
> >
> > No it does not.
>
> For some reason this option and code didn't make it from
> 2.4 to 2.6. It should have some effect on small memory (16Mbyte)
> systems with processor that have more than 16 TLB entries.
Oh, but the CONFIG_PIN_TLB code in head_8xx.S is there. I guess something is missing.
Jocke
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-23 21:55 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHKEGMCLAA.Joakim.Tjernlund@lumentis.se>
On Apr 9, 2005, at 3:03 PM, Joakim Tjernlund wrote:
> yes, but I think these operates on physical addresses which makes it a
> bit harder.
> I still think this can be resolved in fault.c. Replace
> andis. r11, r10, 0x0200 /* If set, indicates store op */
> beq 2f
> in the DTLB Error handler with
> andis. r11, r10, 0x4800 /* If set, indicates invalid pte or
> protection violation */
> bne 2f
> In fault.c you can check if both store and invalid is set
> simultaneously. If it is, clear
> the store flag and continue as usual.
The purpose for the code in TLB Error is to create fast path for
tracking
writable pages as dirty. I think we should stop writing all of this
assembler
code and if we find anything that isn't simply updating the "dirty"
flags, we
should bail out to the fault.c and do whatever is necessary. This
includes
simulating any cache instructions that fail.
As a further performance enhancement, which used to be the standard
mode for 8xx, we should allow the option to mark all writable pages as
dirty when the PTE is created. This eliminates the TLB Error fault in
this
case completely. Since most 8xx systems don't do page swapping, this
has no other effect. If it does page swapping, it may swap more pages
than necessary, or the option can be disabled to do proper paging.
Thanks.
-- Dan
^ permalink raw reply
* RE: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-23 21:51 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <42b1a4ca0138e9576d010ec2754eb29a@embeddededge.com>
>
> On Apr 23, 2005, at 1:35 PM, Joakim Tjernlund wrote:
>
> > Is it possible to handle the _PAGE_ACCESSED handling at pte creation
> > in fault.c instead
> > of doing it for every TLB miss? That should make the TLB Miss handler
> > faster.
>
> No. As part of VM management to determine working sets, it's possible
> to have
> this flag change state but the page to remain valid.
OK, strange though. I would have expected this flag to stay untouched until the
pte is invalidated.
> The cost of
> setting this properly
> in the miss handler is minimal compared to the other stuff that we
> should try
> and streamline.
Well, every instruction counts. I this case we would have saved
2 in ITLB Miss, 3 in DTLB Miss and a cache line write in both.
Would be nice to do away with the kernel space test, but thats a lot harder.
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Dan Malek @ 2005-04-23 21:32 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050423124245.GJ12703@logos.cnet>
On Apr 23, 2005, at 8:42 AM, Marcelo Tosatti wrote:
>> Does CONFIG_PIN_TLB make a difference?
>
> No it does not.
For some reason this option and code didn't make it from
2.4 to 2.6. It should have some effect on small memory (16Mbyte)
systems with processor that have more than 16 TLB entries.
-- Dan
^ permalink raw reply
* RE: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-23 21:31 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050423124245.GJ12703@logos.cnet>
> Hi Joakim,
>
> On Sat, Apr 23, 2005 at 07:23:51PM +0200, Joakim Tjernlund wrote:
> > > Now, what is the best way to bring the performance back to v2.4 levels?
> > >
> > > For this "dd" test, which is dominated by "sys_read/sys_write", I thought
> > > of trying to bring the hotpath functions into the same pages, thus
> > > decreasing the number of page translations required for such tasks.
> > >
> > > Comments are appreciated
> >
> > Does CONFIG_PIN_TLB make a difference?
>
> No it does not.
hmm, strange. I would expect the kernel ITLB Misses to be zero and the kernel DTLB
Misses be a lot smaller. Have any numbers handy?
Jocke
^ permalink raw reply
* Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Dan Malek @ 2005-04-23 21:29 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHCEIICLAA.Joakim.Tjernlund@lumentis.se>
On Apr 23, 2005, at 1:35 PM, Joakim Tjernlund wrote:
> Is it possible to handle the _PAGE_ACCESSED handling at pte creation
> in fault.c instead
> of doing it for every TLB miss? That should make the TLB Miss handler
> faster.
No. As part of VM management to determine working sets, it's possible
to have
this flag change state but the page to remain valid. The cost of
setting this properly
in the miss handler is minimal compared to the other stuff that we
should try
and streamline.
Thanks.
-- Dan
^ permalink raw reply
* Re: ioremap problem with kernel 2.6.11 on mpc8270
From: Dan Malek @ 2005-04-23 21:25 UTC (permalink / raw)
To: clasu; +Cc: linuxppc-embedded
In-Reply-To: <1114268839955.clasu.41340._Jq1rpPPGxteNPNX4EzpwA@luukku.com>
On Apr 23, 2005, at 11:07 AM, clasu@luukku.com wrote:
> It seems to me that the ioremap call fails somehow in 2.6.11 and that
> the page
> tables are not updated correctly.
I can't find any obvious differences that would cause this. I suspect
something
may be different in your platform specific set up or there was some
minor
changes that are required moving your platform specific set up to the
newer
kernel sources.
> I have not been able to find out what causes this but it would make
> may day if
> someone could help me a bit.
In arch/ppc/mm/pgtable.c, about line 481, change the
#define HAVE_BATS 1
to
#define HAVE_BATS 0
and report if that makes any difference.
Thanks.
-- Dan
^ permalink raw reply
* Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Marcelo Tosatti @ 2005-04-23 12:42 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHMEIHCLAA.Joakim.Tjernlund@lumentis.se>
Hi Joakim,
On Sat, Apr 23, 2005 at 07:23:51PM +0200, Joakim Tjernlund wrote:
> > Now, what is the best way to bring the performance back to v2.4 levels?
> >
> > For this "dd" test, which is dominated by "sys_read/sys_write", I thought
> > of trying to bring the hotpath functions into the same pages, thus
> > decreasing the number of page translations required for such tasks.
> >
> > Comments are appreciated
>
> Does CONFIG_PIN_TLB make a difference?
No it does not.
^ permalink raw reply
* RE: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-23 17:35 UTC (permalink / raw)
To: linuxppc-embedded, marcelo.tosatti
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHMEIHCLAA.Joakim.Tjernlund@lumentis.se>
>
> > Now, what is the best way to bring the performance back to v2.4 levels?
> >
> > For this "dd" test, which is dominated by "sys_read/sys_write", I thought
> > of trying to bring the hotpath functions into the same pages, thus
> > decreasing the number of page translations required for such tasks.
> >
> > Comments are appreciated
>
> Does CONFIG_PIN_TLB make a difference?
>
> Jocke
Is it possible to handle the _PAGE_ACCESSED handling at pte creation in fault.c instead
of doing it for every TLB miss? That should make the TLB Miss handler faster.
Jocke
^ permalink raw reply
* [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Joakim Tjernlund @ 2005-04-23 17:23 UTC (permalink / raw)
To: linuxppc-embedded, marcelo.tosatti
> Now, what is the best way to bring the performance back to v2.4 levels?
>
> For this "dd" test, which is dominated by "sys_read/sys_write", I thought
> of trying to bring the hotpath functions into the same pages, thus
> decreasing the number of page translations required for such tasks.
>
> Comments are appreciated
Does CONFIG_PIN_TLB make a difference?
Jocke
^ permalink raw reply
* ioremap problem with kernel 2.6.11 on mpc8270
From: clasu @ 2005-04-23 15:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
I'm porting kernel version 2.6.11 to a custom board with an MPC8270 control=
ler.
The kernel is booting and when it runs the init routine of a custom nand dr=
iver it
generates a machine check exception.
The call to ioremap(0x40000000, 0x2000000) returns an address of
0xe1000000 and the exception is caused by an iowrite8() call to the address
returned by ioremap(). The same happens if the memory address is read.
In further investigations I have found out that the writes and reads are no=
t
mapped to the physical address 0x40000000. ioremap() returned 0xe1000000
and that is also the physical address where the writes and reads are mapped=
to.
(=3Dno mapping).
The same driver (minor changes to struct names) works on the same board in
a linux kernel 2.6.7-rc1. In this kernel ioremap returns the same address
(0xe1000000) as in version 2.6.11 but all accesses are mapped to 0x40000000
as they should be.
I use the same board and same u-boot (1.1.2) to start both kernels.
It seems to me that the ioremap call fails somehow in 2.6.11 and that the p=
age
tables are not updated correctly.
I have not been able to find out what causes this but it would make may day=
if
someone could help me a bit.
Best regards,
-Claus-
...................................................................
Luukku Plus paketilla p=E4=E4set eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.fi/luukku
^ permalink raw reply
* Re: 824x sandpoint and 2.6.x
From: Sam Song @ 2005-04-23 12:16 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
"Mark A. Greer" <mgreer@mvista.com> wrote:
> >had, is it possible to flush the content of
__log_buf
> >after reset?
>
> Sam,
>
> I thought I finally noticed yesterday that you're
> using 2.4. If that is
> the case, you want to dump "log_buf" not
> "__log_buf".
Uh, I copy the above note to this thread to
continue:-)
The turth is that I ported denx 2.4.24 successfully on
my board
and try to port it to 2.6.x. To my understanding,
UART init was
bad for some reason. It was auto configured as 16450
rather than
16550A as 2.4. Besides, ttyS0 iomem base address in
2.6 is different
to the one in 2.4 although they have the same serial
address setting.
I wander which kind of possiblity coud lead to this
result or even better
to point out some useful printk locations to me.
If possible, could you pls show me a right 2.6 boot
process of
sandpoint X3/2? I wanna to find out some nice hints
of it. This
is the first time to me so hard to debug a kernel
before normal
console.
Thanks a lot,
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* [PATCH] ppc32: Fix a sleep issues on some laptops
From: Benjamin Herrenschmidt @ 2005-04-23 3:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
Hi !
Some earlier models of aluminium powerbooks and ibook G4s have a clock
chip that requires some tweaking before and after sleep. It seems that
without that magic incantation to disable and re-enable clock spreading,
RAM isn't properly refreshed during sleep. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-04-12 18:07:50.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-04-22 17:07:30.000000000 +1000
@@ -1590,6 +1590,112 @@
mdelay(10);
}
+
+static void __pmac pmac_tweak_clock_spreading(struct macio_chip* macio, int enable)
+{
+ /* Hack for doing clock spreading on some machines PowerBooks and
+ * iBooks. This implements the "platform-do-clockspreading" OF
+ * property as decoded manually on various models. For safety, we also
+ * check the product ID in the device-tree in cases we'll whack the i2c
+ * chip to make reasonably sure we won't set wrong values in there
+ *
+ * Of course, ultimately, we have to implement a real parser for
+ * the platform-do-* stuff...
+ */
+
+ if (macio->type == macio_intrepid) {
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+
+ while (machine_is_compatible("PowerBook5,2") ||
+ machine_is_compatible("PowerBook5,3") ||
+ machine_is_compatible("PowerBook6,2") ||
+ machine_is_compatible("PowerBook6,3")) {
+ struct device_node *ui2c = of_find_node_by_type(NULL, "i2c");
+ struct device_node *dt = of_find_node_by_name(NULL, "device-tree");
+ u8 buffer[9];
+ u32 *productID;
+ int i, rc, changed = 0;
+
+ if (dt == NULL)
+ break;
+ productID = (u32 *)get_property(dt, "pid#", NULL);
+ if (productID == NULL)
+ break;
+ while(ui2c) {
+ struct device_node *p = of_get_parent(ui2c);
+ if (p && !strcmp(p->name, "uni-n"))
+ break;
+ ui2c = of_find_node_by_type(ui2c, "i2c");
+ }
+ if (ui2c == NULL)
+ break;
+ DBG("Trying to bump clock speed for PID: %08x...\n", *productID);
+ rc = pmac_low_i2c_open(ui2c, 1);
+ if (rc != 0)
+ break;
+ pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_combined);
+ rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_read, 0x80, buffer, 9);
+ DBG("read result: %d,", rc);
+ if (rc != 0) {
+ pmac_low_i2c_close(ui2c);
+ break;
+ }
+ for (i=0; i<9; i++)
+ DBG(" %02x", buffer[i]);
+ DBG("\n");
+
+ switch(*productID) {
+ case 0x1182: /* AlBook 12" rev 2 */
+ case 0x1183: /* iBook G4 12" */
+ buffer[0] = (buffer[0] & 0x8f) | 0x70;
+ buffer[2] = (buffer[2] & 0x7f) | 0x00;
+ buffer[5] = (buffer[5] & 0x80) | 0x31;
+ buffer[6] = (buffer[6] & 0x40) | 0xb0;
+ buffer[7] = (buffer[7] & 0x00) | (enable ? 0xc0 : 0xba);
+ buffer[8] = (buffer[8] & 0x00) | 0x30;
+ changed = 1;
+ break;
+ case 0x3142: /* AlBook 15" (ATI M10) */
+ case 0x3143: /* AlBook 17" (ATI M10) */
+ buffer[0] = (buffer[0] & 0xaf) | 0x50;
+ buffer[2] = (buffer[2] & 0x7f) | 0x00;
+ buffer[5] = (buffer[5] & 0x80) | 0x31;
+ buffer[6] = (buffer[6] & 0x40) | 0xb0;
+ buffer[7] = (buffer[7] & 0x00) | (enable ? 0xd0 : 0xc0);
+ buffer[8] = (buffer[8] & 0x00) | 0x30;
+ changed = 1;
+ break;
+ default:
+ DBG("i2c-hwclock: Machine model not handled\n");
+ break;
+ }
+ if (!changed) {
+ pmac_low_i2c_close(ui2c);
+ break;
+ }
+ pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_stdsub);
+ rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_write, 0x80, buffer, 9);
+ DBG("write result: %d,", rc);
+ pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_combined);
+ rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_read, 0x80, buffer, 9);
+ DBG("read result: %d,", rc);
+ if (rc != 0) {
+ pmac_low_i2c_close(ui2c);
+ break;
+ }
+ for (i=0; i<9; i++)
+ DBG(" %02x", buffer[i]);
+ pmac_low_i2c_close(ui2c);
+ break;
+ }
+}
+
+
static int __pmac
core99_sleep(void)
{
@@ -1601,11 +1707,8 @@
macio->type != macio_intrepid)
return -ENODEV;
- /* The device-tree contains that in the hwclock node */
- if (macio->type == macio_intrepid) {
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
- }
+ /* Disable clock spreading */
+ pmac_tweak_clock_spreading(macio, 0);
/* We power off the wireless slot in case it was not done
* by the driver. We don't power it on automatically however
@@ -1749,11 +1852,8 @@
UN_OUT(UNI_N_CLOCK_CNTL, save_unin_clock_ctl);
udelay(100);
- /* Restore clock spreading */
- if (macio->type == macio_intrepid) {
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- mdelay(40);
- }
+ /* Enable clock spreading */
+ pmac_tweak_clock_spreading(macio, 1);
return 0;
}
@@ -2718,97 +2818,11 @@
MACIO_BIC(HEATHROW_FCR, HRW_SOUND_POWER_N);
}
- /* Hack for bumping clock speed on the new PowerBooks and the
- * iBook G4. This implements the "platform-do-clockspreading" OF
- * property. For safety, we also check the product ID in the
- * device-tree to make reasonably sure we won't set wrong values
- * in the clock chip.
- *
- * Of course, ultimately, we have to implement a real parser for
- * the platform-do-* stuff...
+ /* Some machine models need the clock chip to be properly setup for
+ * clock spreading now. This should be a platform function but we
+ * don't do these at the moment
*/
- while (machine_is_compatible("PowerBook5,2") ||
- machine_is_compatible("PowerBook5,3") ||
- machine_is_compatible("PowerBook6,2") ||
- machine_is_compatible("PowerBook6,3")) {
- struct device_node *ui2c = of_find_node_by_type(NULL, "i2c");
- struct device_node *dt = of_find_node_by_name(NULL, "device-tree");
- u8 buffer[9];
- u32 *productID;
- int i, rc, changed = 0;
-
- if (dt == NULL)
- break;
- productID = (u32 *)get_property(dt, "pid#", NULL);
- if (productID == NULL)
- break;
- while(ui2c) {
- struct device_node *p = of_get_parent(ui2c);
- if (p && !strcmp(p->name, "uni-n"))
- break;
- ui2c = of_find_node_by_type(ui2c, "i2c");
- }
- if (ui2c == NULL)
- break;
- DBG("Trying to bump clock speed for PID: %08x...\n", *productID);
- rc = pmac_low_i2c_open(ui2c, 1);
- if (rc != 0)
- break;
- pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_combined);
- rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_read, 0x80, buffer, 9);
- DBG("read result: %d,", rc);
- if (rc != 0) {
- pmac_low_i2c_close(ui2c);
- break;
- }
- for (i=0; i<9; i++)
- DBG(" %02x", buffer[i]);
- DBG("\n");
-
- switch(*productID) {
- case 0x1182: /* AlBook 12" rev 2 */
- case 0x1183: /* iBook G4 12" */
- buffer[0] = (buffer[0] & 0x8f) | 0x70;
- buffer[2] = (buffer[2] & 0x7f) | 0x00;
- buffer[5] = (buffer[5] & 0x80) | 0x31;
- buffer[6] = (buffer[6] & 0x40) | 0xb0;
- buffer[7] = (buffer[7] & 0x00) | 0xc0;
- buffer[8] = (buffer[8] & 0x00) | 0x30;
- changed = 1;
- break;
- case 0x3142: /* AlBook 15" (ATI M10) */
- case 0x3143: /* AlBook 17" (ATI M10) */
- buffer[0] = (buffer[0] & 0xaf) | 0x50;
- buffer[2] = (buffer[2] & 0x7f) | 0x00;
- buffer[5] = (buffer[5] & 0x80) | 0x31;
- buffer[6] = (buffer[6] & 0x40) | 0xb0;
- buffer[7] = (buffer[7] & 0x00) | 0xd0;
- buffer[8] = (buffer[8] & 0x00) | 0x30;
- changed = 1;
- break;
- default:
- DBG("i2c-hwclock: Machine model not handled\n");
- break;
- }
- if (!changed) {
- pmac_low_i2c_close(ui2c);
- break;
- }
- pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_stdsub);
- rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_write, 0x80, buffer, 9);
- DBG("write result: %d,", rc);
- pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_combined);
- rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_read, 0x80, buffer, 9);
- DBG("read result: %d,", rc);
- if (rc != 0) {
- pmac_low_i2c_close(ui2c);
- break;
- }
- for (i=0; i<9; i++)
- DBG(" %02x", buffer[i]);
- pmac_low_i2c_close(ui2c);
- break;
- }
+ pmac_tweak_clock_spreading(&macio_chips[0], 1);
#endif /* CONFIG_POWER4 */
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Wolfgang Denk @ 2005-04-22 22:40 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20050422222925.GB9158@gate.ebshome.net>
In message <20050422222925.GB9158@gate.ebshome.net> you wrote:
>
> Sure, but tell me then, _WHY_ U-Boot has this warm-reboot entry?
Because a customer payed for it, and it does not hurt (as long as you
don't use it).
> IMHO, Motorola should have implemented normal reset facility, which
> doesn't require any tricks.
Only machines that are supposed to run M$ software need a reset
facility :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
- Dennis Ritchie
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Eugene Surovegin @ 2005-04-22 22:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Paul Gortmaker, linuxppc-embedded
In-Reply-To: <20050422222601.35F18C1510@atlas.denx.de>
On Sat, Apr 23, 2005 at 12:25:56AM +0200, Wolfgang Denk wrote:
> In message <20050422210610.GA9158@gate.ebshome.net> you wrote:
> >
> > This is not relevant, because Linux doesn't use this "checkstop"
> > trick. It directly just jumps to U-Boot warm-reboot entry point.
>
> Which is a bad design desicion, IMHO. If you want to reset a board,
> you should really RESET it (and give all attached peripherals a
> chance to get reset, too), instead of just assuming everything is in
> good shape an it's sufficient to just jump into some boot loader code
> again.
Sure, but tell me then, _WHY_ U-Boot has this warm-reboot entry?
IMHO, Motorola should have implemented normal reset facility, which
doesn't require any tricks.
--
Eugene
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Wolfgang Denk @ 2005-04-22 22:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Paul Gortmaker, linuxppc-embedded
In-Reply-To: <20050422210610.GA9158@gate.ebshome.net>
In message <20050422210610.GA9158@gate.ebshome.net> you wrote:
>
> This is not relevant, because Linux doesn't use this "checkstop"
> trick. It directly just jumps to U-Boot warm-reboot entry point.
Which is a bad design desicion, IMHO. If you want to reset a board,
you should really RESET it (and give all attached peripherals a
chance to get reset, too), instead of just assuming everything is in
good shape an it's sufficient to just jump into some boot loader code
again.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Language shapes the way we think, and determines what we can think
about." - B. L. Whorf
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-22 17:14 UTC (permalink / raw)
To: Joakim Tjernlund, Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <20050409223721.GA27454@logos.cnet>
Dan,
I haven't heard your opinion on Joakim's proposed change yet.
It looks plausible, and its more complete than dcbst's reimplementation
with 8xx specific cache functions (because it also covers userspace dcbst
callers).
I would love to see this getting fixed in v2.6 mainline.
Thanks
On Sat, Apr 09, 2005 at 07:37:21PM -0300, Marcelo Tosatti wrote:
> On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote:
> > >
> > > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
> > >
> > > > 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
> > > > Did you give up about it?
> > >
> > > I think a tlbia() of the vaddr should work here. No sense blowing
> > > away the whole TLB cache for this.
> >
> > Umm, isn't it the other way around? tlbie flushes one TLB whereas tlbia flushes
> > all TLBs.
>
> Yep
>
> > > > What else you think can be done?
> > >
> > > It would be interesting to change __flush_dcache_icache()
> > > to use the 8xx SPR cache operations instead of the dcbst instruction.
> >
> > yes, but I think these operates on physical addresses which makes it a bit harder.
>
> Other than the fact of userspace dcbst users.
>
> > I still think this can be resolved in fault.c. Replace
> > andis. r11, r10, 0x0200 /* If set, indicates store op */
> > beq 2f
> > in the DTLB Error handler with
> > andis. r11, r10, 0x4800 /* If set, indicates invalid pte or protection violation */
> > bne 2f
>
> Why does the current code jump to page fault handler in case of store operation?
>
> Out of curiosity, aren't there any other valid bit combinations for DSISR other
> than 0x4800 which should allow a fastpath DataTLBError ?
>
> I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it
> always refer to the PEM when talking about DSISR bit assignments.
>
> I can't find section "7-15" as you mentioned in the other email.
>
> > In fault.c you can check if both store and invalid is set simultaneously. If it is, clear
> > the store flag and continue as usual.
>
> One point is that by changing the in-kernel dcbst implementation userspace is
> still vulnerable to the problem.
>
> Now fixing the exception handler to deal with such boggosity as Joakim proposes is
> complete - it handles userspace dcbst callers.
>
> > > I wouldn't be surprised if it worked differently, but I'd not be
> > > able to explain it :-)
> > >
> > > Thanks.
> > >
> > > -- Dan
> > >
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Flash Statistics
From: Josh Boyer @ 2005-04-22 22:04 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jeff.Fellin, linuxppc-embedded
In-Reply-To: <20050422215339.GA9488@gate.ebshome.net>
On Fri, 2005-04-22 at 14:53 -0700, Eugene Surovegin wrote:
> On Fri, Apr 22, 2005 at 05:19:17PM -0400, Jeff.Fellin@rflelect.com wrote:
> >
> > I am looking for information in the kernel or elsewhere about flash usage
> > statistics. I'm interested in knowing how
> > many times a sector has been erased and written to. This doesn't have to be
> > for all time, since other tools
> > can erase and write the flash (U-boot), but just what the activity during
> > application processing. We use the
> > flash to store configuration files that are changeable and would like to
> > determine the expected lifetime
> > of the chips at use sites.
> >
> > Any pointers to places where flash statistics are maintained or tools to
> > collect these statistics is
> > appreciated.
>
> Flash datasheet must have this information.
They have information on the maximum number of writes per eraseblock,
yes. But I think Jeff is looking for some statistic gathering tools he
can use to figure out how his application workload is effecting flash.
I doubt that is in any datasheets ;).
josh
^ permalink raw reply
* Re: Flash Statistics
From: Eugene Surovegin @ 2005-04-22 21:53 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF6EA2D85F.3FCDDAC2-ON85256FEB.00750EFB@teal.com>
On Fri, Apr 22, 2005 at 05:19:17PM -0400, Jeff.Fellin@rflelect.com wrote:
>
> I am looking for information in the kernel or elsewhere about flash usage
> statistics. I'm interested in knowing how
> many times a sector has been erased and written to. This doesn't have to be
> for all time, since other tools
> can erase and write the flash (U-boot), but just what the activity during
> application processing. We use the
> flash to store configuration files that are changeable and would like to
> determine the expected lifetime
> of the chips at use sites.
>
> Any pointers to places where flash statistics are maintained or tools to
> collect these statistics is
> appreciated.
Flash datasheet must have this information.
--
Eugene
^ permalink raw reply
* Re: Flash Statistics
From: Josh Boyer @ 2005-04-22 21:41 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF6EA2D85F.3FCDDAC2-ON85256FEB.00750EFB@teal.com>
On Fri, 2005-04-22 at 17:19 -0400, Jeff.Fellin@rflelect.com wrote:
> I am looking for information in the kernel or elsewhere about flash usage
> statistics. I'm interested in knowing how
> many times a sector has been erased and written to. This doesn't have to be
> for all time, since other tools
> can erase and write the flash (U-boot), but just what the activity during
> application processing. We use the
> flash to store configuration files that are changeable and would like to
> determine the expected lifetime
> of the chips at use sites.
>
> Any pointers to places where flash statistics are maintained or tools to
> collect these statistics is
> appreciated.
You might try http://linux-mtd.infradead.org
I'm not aware of any write statistics gathering tools, but MTD is where
they would/should be.
josh
^ permalink raw reply
* Flash Statistics
From: Jeff.Fellin @ 2005-04-22 21:19 UTC (permalink / raw)
To: linuxppc-embedded
I am looking for information in the kernel or elsewhere about flash usage
statistics. I'm interested in knowing how
many times a sector has been erased and written to. This doesn't have to be
for all time, since other tools
can erase and write the flash (U-boot), but just what the activity during
application processing. We use the
flash to store configuration files that are changeable and would like to
determine the expected lifetime
of the chips at use sites.
Any pointers to places where flash statistics are maintained or tools to
collect these statistics is
appreciated.
Thank you for your help in advance.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Eugene Surovegin @ 2005-04-22 21:06 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-embedded
In-Reply-To: <20050422194638.56637.qmail@web60507.mail.yahoo.com>
On Fri, Apr 22, 2005 at 12:46:38PM -0700, Paul Gortmaker wrote:
> I should have asked what version of U-Boot you were using.
This is not relevant, because Linux doesn't use this "checkstop"
trick. It directly just jumps to U-Boot warm-reboot entry point.
--
Eugene
^ permalink raw reply
* Re: [26-devel] v2.6 performance slowdown on MPC8xx: Measuring TLB cache misses
From: Marcelo Tosatti @ 2005-04-22 15:39 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: 26-devel, linux-ppc-embedded
In-Reply-To: <42689729.3030100@intracom.gr>
On Fri, Apr 22, 2005 at 09:18:17AM +0300, Pantelis Antoniou wrote:
> Marcelo Tosatti wrote:
> >On Thu, Apr 21, 2005 at 03:32:39PM -0300, Marcelo Tosatti wrote:
> >
> >>Capture session of /proc/tlbmiss with 1 second interval:
> >
> >
> >Forgot to attach /proc/tlbmiss patch, here it is.
> >
> >
> [snip]
>
> >
> >
>
> Thanks Marcelo.
>
> I'll try to run this on my 870 board & mail the results.
Hi,
Here goes more data about the v2.6 performance slowdown on MPC8xx.
Thanks Benjamin for the TLB miss counter idea!
This are results of the following test script which zeroes the TLB counters,
copies 16MB of data from memory to memory using "dd", and reads the counters
again.
--
#!/bin/bash
echo 0 > /proc/tlbmiss
time dd if=/dev/zero of=file bs=4k count=3840
cat /proc/tlbmiss
--
The results:
v2.6: v2.4: delta
[root@CAS root]# sh script [root@CAS root]# sh script
real 0m4.241s real 0m3.440s
user 0m0.140s user 0m0.090s
sys 0m3.820s sys 0m3.330s
I-TLB userspace misses: 142369 I-TLB userspace misses: 2179 ITLB u: 139190
I-TLB kernel misses: 118288 I-TLB kernel misses: 1369 ITLB k: 116319
D-TLB userspace misses: 222916 D-TLB userspace misses: 180249 DTLB u: 38667
D-TLB kernel misses: 207773 D-TLB kernel misses: 167236 DTLB k: 38273
The sum of all TLB miss counter delta's between v2.4 and v2.6 is:
139190 + 116319 + 38667 + 38273 = 332449
Multiplied by 23 cycles, which is the average wait time to read a
page translation miss from memory:
332449 * 23 = 7646327 cycles.
Which is about 16% of 48000000, the total number of cycles this CPU
performs on one second. Its very likely that there is a significant
indirect effect of this TLB miss increase, other than the wasted
cycles to bring the page tables from memory: exception execution time
and context switching.
Checking "time" output, we can see 1s of slowdown:
[root@CAS root]# time dd if=/dev/zero of=file bs=4k count=3840
v2.4: v2.6: diff
real 0m3.366s real 0m4.360s 0.994s
user 0m0.080s user 0m0.111s 0.31s
sys 0m3.260s sys 0m4.218s 0.958s
Mostly caused by increased kernel execution time.
This proves that the slowdown is, in great part, due to increased
translation cache trashing.
Now, what is the best way to bring the performance back to v2.4 levels?
For this "dd" test, which is dominated by "sys_read/sys_write", I thought
of trying to bring the hotpath functions into the same pages, thus
decreasing the number of page translations required for such tasks.
Comments are appreciated.
^ permalink raw reply
* pthread debugging problem
From: Mark Chambers @ 2005-04-22 19:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
I am debugging a simple program with several threads, using pthreads.
printf's tell me that the threading is working, but I am unable to debug
the program with gdb (gdbserver on the target). I get spurious
'Program received signal SIG32, Real-time even 32' messages.
I'm using a stock ELDK tree via NFS boot. I couldn't tell you the ELDK
version but I've listed some of the components below.
I've found postings in the general linux community, but they don't seem
to apply in this case. I've compiled a late gdb (6.2), tried later versions
of all the libraries that seem relevant, to no avail. Any ideas? Or,
equally valuable, is anybody debugging pthreads successfully on ppc,
what is your setup?
Thanks,
Mark Chambers
versions:
libc-2.2.1
libpthread-0.9.so
kernel - 2.4.19
[-- Attachment #2: Type: text/html, Size: 1986 bytes --]
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Paul Gortmaker @ 2005-04-22 19:46 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
I should have asked what version of U-Boot you were using. I've had
U-Boot 1.1.1 on this thing from the beginning, but I've heard that some
people are sticking with 1.0 on production stuff.
I've found that I can't use the watchdog timer for a reboot, since it is
"write once" (SYCPR) and I'm guessing U-Boot writes to it at boot.
As a different twist, I tried doing a reset like the m8xx does, as shown
below, but that just caused a hang as well, so I'm wondering if the
problem is more low level (board isn't set up properly, etc.)
Paul.
/*
*This is a tweaked version of the m8xx_restart.
*/
static void
sbc82xx_restart(char *cmd)
{
__volatile__ unsigned char dummy;
unsigned long msr;
volatile car_cpm2_t *cc = &cpm2_immr->im_clkrst;
msr = mfmsr();
mtmsr(msr & ~MSR_EE);
__asm__ __volatile__("": : :"memory");
/* Checkstop reset enable -- Sec. 5.3 of MPC8260UM.pdf */
cc->car_rmr = 0x80000000;
msr = mfmsr();
mtmsr(msr & ~MSR_ME);
dummy = cc->res[0];
BUG();
}
--- Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Apr 12, 2005 at 11:14:35AM -0700, Paul Gortmaker wrote:
> > I've been trying to get a WRS 8265 to do a warm reboot, and found some
> > things that I am wondering about.
> >
> > Firstly, is anyone having success on having "reboot" restart the
> machine
> > on a similar platform?
> >
> > Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h)
> and I
> > was wondering if this matches any platforms out there. On this board,
> the
> > place where U-Boot lives is 0xFFF00104 -- and I've verified this by
> typing
> > "g fff00104" at the U-Boot prompt which causes U-Boot to simply
> restart.
> >
> > I've changed the value in sbc82xx.h and now at the reboot, instead of
> a
> > register dump, it simply hangs. Looking at m8260_gorom (in
> kernel/head.S)
> > it clears the MSR_EE (ext int. enable) bit in the MSR before jumping
> --
> > but I was wondering if there are other bits in MSR that need to be
> > cleared; e.g. instruction relocation enable and data relocation enable
> > (MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf
> from
> > Freescale.
> >
> > I guess if somebody even said "it works for me" then I'd have a better
> > feeling thinking that what is done to the MSR currently is sufficient.
>
> I don't have any problems using reboot() on 8248 based board.
> Kernel.org-based 2.4.29 tree.
>
> I have U-Boot at 0xfe00'0000, and I use 0xfe00'0104 as a second
> parameter for m8260_gorom. Also make sure that first parameter is also
> correct:
>
> m8260_gorom(__pa(__res), 0xfe000104);
>
> --
> Eugene
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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