* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-07 19:38 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <BCEFJBPJCGFCNMMMIDBHGEGHCLAA.Joakim.Tjernlund@lumentis.se>
Joakim,
On Thu, Apr 07, 2005 at 10:35:30PM +0200, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> > Sent: den 7 april 2005 14:00
> > On Wed, Apr 06, 2005 at 11:24:46PM +0200, Joakim Tjernlund wrote:
> > > > On Tue, Apr 05, 2005 at 11:51:42PM +0200, Joakim Tjernlund wrote:
> > > > > Hi Marcelo
> > > > >
> > > > > Reading your report it doesn't sound likely but I will ask anyway:
> > > > > Is it possible that the problem you are seeing isn't caused by the
> > > > > "famous" CPU bug mentioned here:
> > > > > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016351.html
> > > > >
> > > > > The DTLB error handler needs DAR to be set correctly and since the
> > > > > dcbX instructions doesn't set DAR in either DTLB Miss nor DTLB Error you
> > > > > may end up trying to fix the wrong address.
> > > >
> > > > Hi Joakim,
> > > >
> > > > First of all, thanks your care!
> > >
> > > NP, I want to be able to run 8xx on 2.6 in the future.
> > >
> > > >
> > > > Well, I dont think the above issue is exactly what we're hitting because
> > > > DAR is correctly updated on our case with "dcbst".
> > >
> > > Are you sure? Cant remeber all details but this looks a bit strange to me
> > > SPR 826 : 0x00001f00 7936
> > > is not 0x00001 supposed to be the physical page?
> >
> > SPR 826 contains the page attributes, not Physical Page Number (which is held
> > by SPR 825).
>
> Yes, my memory is getting really bad :)
>
> Does SPR 825 hould the correct physical page? 0x000001e0 looks like
> Zero to me(I should probably bring the manual home so i don't have the rely on
> my bad memory :)
Yes, it is zero. That is because there is no pte entry for the page yet (DataStoreTLBMiss
sets the pte even if its zero). Thats when DataTLBError (EA present in TLB entry but valid
bit not set) gets called.
> > > Also DSISR: C2000000 looks strange and "impossible". Are you sure this value
> > > is correct?
> >
> > As defined by the PEM, bit 1 indicates "data-store error exception", bit 2
> > indicates:
I meant "bit 0 and bit 1".
> > "Set if the translation of an attempted access is not found in the primary hash
> > table entry group (HTEG), or in the rehashed secondary HTEG, or in the range of a
> > DBAT register (page fault condition); otherwise cleared."
> >
> > And bit 6 indicates a store operation (shouldnt be set).
>
> Yes, but bit 0 is also set and if I remember correctly(don't have the manual handy)
> it should always be zero?
Well, bit 0 and bit 1 are set.
> > > Don't understand why the "tlbie()" call works around the problem. Can you
> > > explain that a bit more?
> >
> > It must be because the TLB entry is now removed from the cache, which avoids
> > dcbst from faulting as a store.
> >
> > There must be some relation to the invalid present TLB entry and dcbst
> > misbehaviour.
> >
> > I didnt check what happens with the TLB after tlbie(), I should do that.
> > But I suppose it gets wiped off?
>
> Unless the pte gets populated(valid) before the next TLB miss I think you
> will repeat the same sequence that caused the error in the first place.
> So why does that work?
It does get populated.
The sequence is:
1) userspace access triggers DataTLBMiss
2) DataTLBMiss sets TLB from Linux pte. At this stage pte entry is still
zeroed (pte table entry clear). Thats why PPN points to page "00000".
3) DataTLBError (TLB EA match but valid bit not set) - jumps to page fault
handler
4) do_no_page()
- allocates a page
- set pte accordingly
- update_mmu_cache() (dcbst access faults as a write)
So, there must be some relation over dcbst's misbehaviour and the _invalid_
zero RPN TLB entry.
Thing is dcbst is not supposed to fault as a store operation, from what PEM
indicates.
As I understand 8xx deviates from other PPC's in many aspects. Dan says:
"The PEM cache instructions are all implemented in a microcode that
uses the 8xx unique cache control SPRs. Depending upon the state
of the cache and MMU, it seems in some cases the EA translation is
subject to a "normal" protection match instead of a load operation
match.
The behavior of these operations isn't consistent across all of the 8xx
processor revisions, especially with early silicon if people are still
using those. During conversations with Freescale engineers, it seems
the only guaranteed operation was to use the 8xx unique SPRs, but
I think I only did that in 8xx specific functions."
I'll check what the tlbie does precisely (tomorrow). I suppose it wipes the TLB
entry completly.
Would be nice to have someone from 8xx team look into this?
> > > > The problem is that it is treated as a write operation, but shouldnt.
> > > >
> > > > Maybe it is related to dcbst's inability to set DAR?
> > >
> > > Could be, but even if it isn't you are in trouble when dcbX instr.
> > > generates DTLB Misses/Errors Sooner or later you will end up with
> > > strange SEGV or hangs.
> >
> > Hangs due to the dcbX misbehaviour wrt DAR setting, you mean? (which your
> > patch corrects).
>
> Yes.
>
> >
> > Yep, that makes sense.
> >
> > > > BTW, about the CPU15 bug fix, has there been any effort to port/merge
> > > > it in v2.6 ?
> > >
> > > None that I know.
I'll try cpu15.c on v2.6 tomorrow.
^ permalink raw reply
* Re: [PATCH 3/3] PPC440EP: MTD support for the Bamboo Board
From: Josh Boyer @ 2005-04-08 1:59 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <1112889944.24527.325.camel@rhino.az.mvista.com>
On Thu, 2005-04-07 at 09:05 -0700, Wade Farnsworth wrote:
> On Wed, 2005-04-06 at 17:58, Josh Boyer wrote:
> >
> > ... so any reason why NAND_ECC_SOFT is used instead of making use of the
> > ECC registers that come with the NDFC?
>
> Mainly because I haven't looked at what it would take to get HW ECC
> working yet. I'll look at this when I have time, but until then at
> least the NAND flashes are functional.
Ok, I figured that was the case and you're absolutely right. HW ECC
could be considered more of a feature, and I'd rather have usable NAND
now than have to wait longer ;).
> >
> > Overall, I think the patch looks good. Care to send it to the MTD
> > maintainers so it gets in their CVS tree?
>
> Will do.
Thanks. I gave them a heads up, so they'll be looking for it.
josh
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-08 2:09 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050407193846.GE19449@logos.cnet>
On Apr 7, 2005, at 3:38 PM, Marcelo Tosatti wrote:
> Would be nice to have someone from 8xx team look into this?
I'll look into it and find some solution. I suspect it is an
interaction with the previous TLB miss and the behavior
of the dcbst TLB look up. Perhaps, if we ensure the
TLB entry is not valid at the time of the dcbst, it will work.
This is why the tlbie() I added as a hack a long time
ago made the "problem" disappear. The other dcbxx
instructions in the code work on already existing pages,
while this one is a special case of a miss on a page
that doesn't exist.
Thanks.
-- Dan
^ permalink raw reply
* RE: 8xx v2.6 TLB problems and suggested workaround
From: Joakim Tjernlund @ 2005-04-08 8:01 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050407193846.GE19449@logos.cnet>
Hi Marcelo
> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> Joakim,
>
> On Thu, Apr 07, 2005 at 10:35:30PM +0200, Joakim Tjernlund wrote:
> > > -----Original Message-----
> > > From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> > > Sent: den 7 april 2005 14:00
> > > On Wed, Apr 06, 2005 at 11:24:46PM +0200, Joakim Tjernlund wrote:
> > > > > On Tue, Apr 05, 2005 at 11:51:42PM +0200, Joakim Tjernlund wrote:
> > > > > > Hi Marcelo
> > > > > >
> > > > > > Reading your report it doesn't sound likely but I will ask anyway:
> > > > > > Is it possible that the problem you are seeing isn't caused by the
> > > > > > "famous" CPU bug mentioned here:
> > > > > > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016351.html
> > > > > >
> > > > > > The DTLB error handler needs DAR to be set correctly and since the
> > > > > > dcbX instructions doesn't set DAR in either DTLB Miss nor DTLB Error you
> > > > > > may end up trying to fix the wrong address.
> > > > >
> > > > > Hi Joakim,
> > > > >
> > > > > First of all, thanks your care!
> > > >
> > > > NP, I want to be able to run 8xx on 2.6 in the future.
> > > >
> > > > >
> > > > > Well, I dont think the above issue is exactly what we're hitting because
> > > > > DAR is correctly updated on our case with "dcbst".
> > > >
> > > > Are you sure? Cant remeber all details but this looks a bit strange to me
> > > > SPR 826 : 0x00001f00 7936
> > > > is not 0x00001 supposed to be the physical page?
> > >
> > > SPR 826 contains the page attributes, not Physical Page Number (which is held
> > > by SPR 825).
> >
> > Yes, my memory is getting really bad :)
> >
> > Does SPR 825 hould the correct physical page? 0x000001e0 looks like
> > Zero to me(I should probably bring the manual home so i don't have the rely on
> > my bad memory :)
>
> Yes, it is zero. That is because there is no pte entry for the page yet (DataStoreTLBMiss
> sets the pte even if its zero). Thats when DataTLBError (EA present in TLB entry but valid
> bit not set) gets called.
I see.
>
> > > > Also DSISR: C2000000 looks strange and "impossible". Are you sure this value
> > > > is correct?
> > >
> > > As defined by the PEM, bit 1 indicates "data-store error exception", bit 2
> > > indicates:
>
> I meant "bit 0 and bit 1".
>
> > > "Set if the translation of an attempted access is not found in the primary hash
> > > table entry group (HTEG), or in the rehashed secondary HTEG, or in the range of a
> > > DBAT register (page fault condition); otherwise cleared."
> > >
> > > And bit 6 indicates a store operation (shouldnt be set).
> >
> > Yes, but bit 0 is also set and if I remember correctly(don't have the manual handy)
> > it should always be zero?
I was looking at the DTLB Error excetion(p. 7-15) in the MPC860 User's Manual. There
bit 1 = invalid TLB
bit 4 = protection violation
bit 6 = store operation
the rest is always zero.
Thats why DSISR = C2000000 looks somewhat impossible since bit 0 is set and that one
should always be zero.
hmm, I just remembered that there is a comment in mm/fault.c that 8xx always set bit 0 even
though it shouldn't. There is also a 8xx specific test with bit 3(0x1000000) in fault.c but
bit 3 is always zero according the MPC860 Manual for a DTLB Error.
Then we end up with bit 1(invalid TLB) and bit 6(store operation) set. Maybe one
could make the DTLB Error handler test if bit 1 is set and then branch to
DataAccess and then deal with the problem in fault.c?
>
> Well, bit 0 and bit 1 are set.
>
> > > > Don't understand why the "tlbie()" call works around the problem. Can you
> > > > explain that a bit more?
> > >
> > > It must be because the TLB entry is now removed from the cache, which avoids
> > > dcbst from faulting as a store.
> > >
> > > There must be some relation to the invalid present TLB entry and dcbst
> > > misbehaviour.
> > >
> > > I didnt check what happens with the TLB after tlbie(), I should do that.
> > > But I suppose it gets wiped off?
> >
> > Unless the pte gets populated(valid) before the next TLB miss I think you
> > will repeat the same sequence that caused the error in the first place.
> > So why does that work?
>
> It does get populated.
>
> The sequence is:
>
> 1) userspace access triggers DataTLBMiss
>
> 2) DataTLBMiss sets TLB from Linux pte. At this stage pte entry is still
> zeroed (pte table entry clear). Thats why PPN points to page "00000".
>
> 3) DataTLBError (TLB EA match but valid bit not set) - jumps to page fault
> handler
>
> 4) do_no_page()
> - allocates a page
> - set pte accordingly
> - update_mmu_cache() (dcbst access faults as a write)
>
> So, there must be some relation over dcbst's misbehaviour and the _invalid_
> zero RPN TLB entry.
>
> Thing is dcbst is not supposed to fault as a store operation, from what PEM
> indicates.
Ah, now I get it. Thanks.
Jocke
^ permalink raw reply
* Re: Fw: Problem with NTP on (embedded) PPC, patch and RFC
From: Gabriel Paubert @ 2005-04-08 8:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Giovambattista Pulcini
In-Reply-To: <20050407181726.GS3396@smtp.west.cox.net>
On Thu, Apr 07, 2005 at 11:17:26AM -0700, Tom Rini wrote:
> > Date: Fri, 11 Mar 2005 14:16:32 +0100
> > From: Giovambattista Pulcini <gpulcini@swintel.it>
> > To: LKML <linux-kernel@vger.kernel.org>
> > Subject: Problem with NTP on (embedded) PPC, patch and RFC
> >
> >
> > Hi,
> >
> > On an embedded device based on the IBM 405GP, but this may be a general
> > problem for most PPC platforms except for chrp and gemini, the NTP
> > utility 'ntptime' always returns error code 5 (TIME_ERROR) even after
> > that NTP status reaches the PLL and FLL state. Analysis of problem
> > showed that the time_state variable set to TIME_ERROR by
> > do_settimeofday() is never set back to TIME_OK.
> > I found the problem in 2.4.10-1 (Lynuxworks BlueCat) but I also checked
> > the 2.6.11 and found similar problem. Many architectures under arch/ppc
> > may be affected with the exception of chrp and gemini.
> >
> > Steps to reproduce:
> > On a PowerPC (non-CHRP) platform, set the system date with 'date',
> > configure and start the NTP daemon as client of a working NTP server.
> > Wait for it to reach the PLL/FLL state. Issue the 'ntptime' command and
> > check that the following two errors never disappear no matter how long
> > you let it running: "ntp_gettime() returns code 5 (ERROR)",
> > "ntp_adjtime() returns code 5 (ERROR)".
> >
> > Detailed analysis:
> > AFAIK NTP relies on the global time_state variable which is statically
> > initialized to TIME_OK (kernel/timer.c). The ntptime utility calls
> > adjtimex() which results in a call to do_adjtimex() and prints its
> > return value which is basically the value of time_state. It is changed
> > by (kernel/timer.c)second_overflow() and by the
> > (kernel/time.c)do_adjtimex() state machine.
> > These two functions never set time_state to TIME_OK once it has been set
> > to TIME_ERROR.
> > Also, do_settimeofday() sets the STA_UNSYNC flag in time_status and sets
> > time_state to TIME_ERROR (in ppc but not in ppc64 nor in x86).
> > The function (arch/ppc/kernel/time.c)timer_interrupt() calls the
> > ppc_md.set_rtc_time() when certain conditions are met, as follows
> > (time.c:171):
> >
> > if ( ppc_md.set_rtc_time && (time_status & STA_UNSYNC) == 0 &&
> > xtime.tv_sec - last_rtc_update >= 659 &&
> > abs(xtime.tv_usec - (1000000-1000000/HZ)) < 500000/HZ &&
> > jiffies - wall_jiffies == 1) {
> > if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) == 0)
> >
> > In the CHRP architecture (see arch/ppc/platforms/chrp_*) the specific
> > implementation of the set_rtc_time(), chrp_set_rtc_time(), has a check
> > like this (chrp_time.c:76):
> >
> > if ( (time_state == TIME_ERROR) || (time_state == TIME_BAD) )
> > time_state = TIME_OK;
> >
> > which is the only chance for the time_state to be set back to TIME_OK
> > after a do_settimeofday(). In other platforms this is not done.
> >
> >
> > Proposed patch:
> > This change should make NTP to work on any ppc platform, while not
> > breaking chrp and gemini. Although I've tested it only on mine.
> > --- linux-2.6.11/arch/ppc/kernel/time.c 2005-03-02 08:38:17.000000000 +0100
> > +++ linux/arch/ppc/kernel/time.c 2005-03-08 14:16:56.000000000 +0100
> > @@ -272,7 +272,6 @@
> >
> > time_adjust = 0; /* stop active adjtime() */
> > time_status |= STA_UNSYNC;
> > - time_state = TIME_ERROR; /* p. 24, (a) */
> > time_maxerror = NTP_PHASE_LIMIT;
> > time_esterror = NTP_PHASE_LIMIT;
> > write_sequnlock_irqrestore(&xtime_lock, flags);
> >
> >
> > My question:
> > I've read some documentation but I am by no means an expert in the NTP
> > kernel support implementation. So I ask you where the time_state should
> > be reset to TIME_OK. Should this be done by the <platform>set_rtc_time() ?
> > Or, as in the x86 case, do_settimeofday should not set time_state to
> > TIME_ERROR ?
> >
> >
> > Giovambattista Pulcini
>
> So, digging back to 2.2.20 even, i386 does not have this TIME_ERROR
> line, and we do. Gabriel, as guru of all things NTP-related, can you
> please shed some enlightenment on what should be fixed? Should we drop
> that line? Make the various RTC drivers do the check CHRP does (which
> at first thought seems like a 'Hey, that's wrong, let me kludge it' kind
> of thing. Thanks.
I've been looking into my own archives and this line predates my
timekeeping patches, which entered the official kernel tree sometime
in the 2.4.0-test series I believe.
Well, I see that time_state is exclusively used for leap second
processing, so it has nothing to do in the arch specific code.
Please remove all its uses, the only thing that _might_ make sense
is to try to update the RTC sooner in kernel/timer.c (i.e., set
last_rtc_update to current time -12 minutes when we switch back
to TIME_OK so that it will be updated asap). But I don't think
it's worth worrying at this level of detail.
Now I want to be able to disable is the time interpolator when
a leap second comes in. The interpolation is the right thing,
or at least the less invasive, thing to do for many users.
It is however the worst thing that can happen when driving a
telescope: the earth does not start rotating a fraction of a
percent faster or slower for 20 minutes or so :-)
However, there are other problems with timekeeping in recent
kernels. I'd like to fix them, but I'm short on time (no pun
intended) and right now trying to get out of the whole
bitkeeper fiasco.
Regards,
Gabriel
^ permalink raw reply
* [PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
From: Chris Elston @ 2005-04-08 8:17 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
This patch adds the hooks into the PPC7D platforms file to
support the DS1337 RTC device as the clock device for the
PPC7D board.
Signed-off-by: Chris Elston <chris.elston@radstone.co.uk>
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
[-- Attachment #2: ppc7d_rtc_hooks.patch --]
[-- Type: application/octet-stream, Size: 2008 bytes --]
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:28:51.000000000 +0100
@@ -68,6 +68,7 @@
#define PPC7D_RST_PIN 17 /* GPP17 */
extern u32 mv64360_irq_base;
+extern spinlock_t rtc_lock;
static struct mv64x60_handle bh;
static int ppc7d_has_alma;
@@ -75,6 +76,11 @@
extern void gen550_progress(char *, unsigned short);
extern void gen550_init(int, struct uart_port *);
+/* FIXME - move to h file */
+extern int ds1337_do_command(int id, int cmd, void *arg);
+#define DS1337_GET_DATE 0
+#define DS1337_SET_DATE 1
+
/* residual data */
unsigned char __res[sizeof(bd_t)];
@@ -1236,6 +1248,38 @@
printk(KERN_INFO "Radstone Technology PPC7D\n");
if (ppc_md.progress)
ppc_md.progress("ppc7d_setup_arch: exit", 0);
+
+}
+
+/* Real Time Clock support.
+ * PPC7D has a DS1337 accessed by I2C.
+ */
+static ulong ppc7d_get_rtc_time(void)
+{
+ struct rtc_time tm;
+ int result;
+
+ spin_lock(&rtc_lock);
+ result = ds1337_do_command(0, DS1337_GET_DATE, &tm);
+ spin_unlock(&rtc_lock);
+
+ if (result == 0)
+ result = mktime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
+
+ return result;
+}
+
+static int ppc7d_set_rtc_time(unsigned long nowtime)
+{
+ struct rtc_time tm;
+ int result;
+
+ spin_lock(&rtc_lock);
+ to_tm(nowtime, &tm);
+ result = ds1337_do_command(0, DS1337_SET_DATE, &tm);
+ spin_unlock(&rtc_lock);
+
+ return result;
}
/* This kernel command line parameter can be used to have the target
@@ -1293,6 +1337,10 @@
data8 |= 0x07;
outb(data8, PPC7D_CPLD_LEDS);
+ /* Hook up RTC. We couldn't do this earlier because we need the I2C subsystem */
+ ppc_md.set_rtc_time = ppc7d_set_rtc_time;
+ ppc_md.get_rtc_time = ppc7d_get_rtc_time;
+
pr_debug("%s: exit\n", __FUNCTION__);
}
^ permalink raw reply
* [PATCH 2.6.12-rc2 1/2] ppc32: fix for misreported SDRAM size on Radstone PPC7D platform
From: Chris Elston @ 2005-04-08 8:17 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
This patch fixes the SDRAM output from /proc/cpuinfo.
The previous code assumed that there was only one bank
of SDRAM, and that the size in the memory configuration
register was the total size.
Signed-off-by: Chris Elston <chris.elston@radstone.co.uk>
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
[-- Attachment #2: ppc7d_sdram_size.patch --]
[-- Type: application/octet-stream, Size: 2015 bytes --]
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:28:51.000000000 +0100
@@ -253,6 +259,8 @@
u8 val1, val2;
static int flash_sizes[4] = { 64, 32, 0, 16 };
static int flash_banks[4] = { 4, 3, 2, 1 };
+ static int sdram_bank_sizes[4] = { 128, 256, 512, 1 };
+ int sdram_num_banks = 2;
static char *pci_modes[] = { "PCI33", "PCI66",
"Unknown", "Unknown",
"PCIX33", "PCIX66",
@@ -279,13 +287,17 @@
(val1 == PPC7D_CPLD_MB_TYPE_PLL_100) ? 100 :
(val1 == PPC7D_CPLD_MB_TYPE_PLL_64) ? 64 : 0);
+ val = inb(PPC7D_CPLD_MEM_CONFIG);
+ if (val & PPC7D_CPLD_SDRAM_BANK_NUM_MASK) sdram_num_banks--;
+
val = inb(PPC7D_CPLD_MEM_CONFIG_EXTEND);
- val1 = val & PPC7D_CPLD_SDRAM_BANK_SIZE_MASK;
- seq_printf(m, "SDRAM\t\t: %d%c",
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_128M) ? 128 :
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_256M) ? 256 :
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_512M) ? 512 : 1,
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_1G) ? 'G' : 'M');
+ val1 = (val & PPC7D_CPLD_SDRAM_BANK_SIZE_MASK) >> 6;
+ seq_printf(m, "SDRAM\t\t: %d banks of %d%c, total %d%c",
+ sdram_num_banks,
+ sdram_bank_sizes[val1],
+ (sdram_bank_sizes[val1] < 128) ? 'G' : 'M',
+ sdram_num_banks * sdram_bank_sizes[val1],
+ (sdram_bank_sizes[val1] < 128) ? 'G' : 'M');
if (val2 & PPC7D_CPLD_MB_TYPE_ECC_FITTED_MASK) {
seq_printf(m, " [ECC %sabled]",
(val2 & PPC7D_CPLD_MB_TYPE_ECC_ENABLE_MASK) ? "en" :
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.h 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.h 2005-04-07 12:28:51.000000000 +0100
@@ -240,6 +240,7 @@
#define PPC7D_CPLD_FLASH_CNTL 0x086E
/* MEMORY_CONFIG_EXTEND */
+#define PPC7D_CPLD_SDRAM_BANK_NUM_MASK 0x02
#define PPC7D_CPLD_SDRAM_BANK_SIZE_MASK 0xc0
#define PPC7D_CPLD_SDRAM_BANK_SIZE_128M 0
#define PPC7D_CPLD_SDRAM_BANK_SIZE_256M 0x40
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Gabriel Paubert @ 2005-04-08 8:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <05453aab0716da8fcade8f835418d680@freescale.com>
On Wed, Apr 06, 2005 at 04:33:14PM -0500, Kumar Gala wrote:
> Here is a version that works if CONFIG_PTE_64BIT is defined. If we
> like this, I can simplify the pte_update so we dont need the (unsigned
> long)(p+1) - 4) trick anymore. Let me know.
>
> - kumar
>
> #ifdef CONFIG_PTE_64BIT
> static inline unsigned long long pte_update(pte_t *p, unsigned long clr,
> unsigned long set)
> {
> unsigned long long old;
> unsigned long tmp;
>
> __asm__ __volatile__("\
> 1: lwarx %L0,0,%4\n\
> lwzx %0,0,%3\n\
> andc %1,%L0,%5\n\
> or %1,%1,%6\n\
> stwcx. %1,0,%4\n\
> bne- 1b"
> : "=&r" (old), "=&r" (tmp), "=m" (*p)
> : "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r" (set),
> "m" (*p)
Are you sure of your pointer arithmetic? I believe that
you'd rather want to use (unsigned char)(p)+4. Or even better:
:"r" (p), "b" (4), "r" (clr), "r" (set)
and change the first line to: lwarx %L0,%4,%3.
Even more devious, you don't need the %4 parameter:
li %L0,4
lwarx %L0,%L0,%3
since %L0 cannot be r0. This saves one register.
> : "cc" );
On PPC, I always prefer saying cr0 over cc. Maybe it's just
me, but it's the canonical register name in the architecture.
Gabriel
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
From: Andrew Morton @ 2005-04-08 8:28 UTC (permalink / raw)
To: Chris Elston; +Cc: linuxppc-embedded
In-Reply-To: <F38DEABE0E171746B133C1ABBD142D9703691AEA@radmail.Radstone.Local>
"Chris Elston" <chris.elston@radstone.co.uk> wrote:
>
> This patch adds the hooks into the PPC7D platforms file to
> support the DS1337 RTC device as the clock device for the
> PPC7D board.
The attachment has all sorts of binary microsofty gunk in it.
^ permalink raw reply
* [PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
From: Chris Elston @ 2005-04-08 8:43 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
This=20patch=20adds=20the=20hooks=20into=20the=20PPC7D=20platforms=20file=20=
to
support=20the=20DS1337=20RTC=20device=20as=20the=20clock=20device=20for=20=
the=20
PPC7D=20board.
Signed-off-by:=20Chris=20Elston=20<chris.elston@radstone.co.uk>
---=20linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.c
2005-04-07=2012:31:43.000000000=20+0100
+++=20linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.c
2005-04-07=2012:28:51.000000000=20+0100
@@=20-68,6=20+68,7=20@@
=20#define=20PPC7D_RST_PIN=09=09=0917=20=09/*=20GPP17=20*/
=20
=20extern=20u32=20mv64360_irq_base;
+extern=20spinlock_t=20rtc_lock;
=20
=20static=20struct=20mv64x60_handle=20bh;
=20static=20int=20ppc7d_has_alma;
@@=20-75,6=20+76,11=20@@
=20extern=20void=20gen550_progress(char=20*,=20unsigned=20short);
=20extern=20void=20gen550_init(int,=20struct=20uart_port=20*);
=20
+/*=20FIXME=20-=20move=20to=20h=20file=20*/
+extern=20int=20ds1337_do_command(int=20id,=20int=20cmd,=20void=20*arg);
+#define=20DS1337_GET_DATE=20=20=20=20=20=20=20=20=200
+#define=20DS1337_SET_DATE=20=20=20=20=20=20=20=20=201
+
=20/*=20residual=20data=20*/
=20unsigned=20char=20__res[sizeof(bd_t)];
=20
@@=20-1236,6=20+1248,38=20@@
=20=09printk(KERN_INFO=20"Radstone=20Technology=20PPC7D\n");
=20=09if=20(ppc_md.progress)
=20=09=09ppc_md.progress("ppc7d_setup_arch:=20exit",=200);
+
+}
+
+/*=20Real=20Time=20Clock=20support.
+=20*=20PPC7D=20has=20a=20DS1337=20accessed=20by=20I2C.
+=20*/
+static=20ulong=20ppc7d_get_rtc_time(void)
+{
+=20=20=20=20=20=20=20=20struct=20rtc_time=20tm;
+=20=20=20=20=20=20=20=20int=20result;
+
+=20=20=20=20=20=20=20=20spin_lock(&rtc_lock);
+=20=20=20=20=20=20=20=20result=20=3D=20ds1337_do_command(0,=20DS1337_GET_=
DATE,=20&tm);
+=20=20=20=20=20=20=20=20spin_unlock(&rtc_lock);
+
+=20=20=20=20=20=20=20=20if=20(result=20=3D=3D=200)
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20result=20=3D=20mktime(tm.=
tm_year,=20tm.tm_mon,=20tm.tm_mday,
tm.tm_hour,=20tm.tm_min,=20tm.tm_sec);
+
+=20=20=20=20=20=20=20=20return=20result;
+}
+
+static=20int=20ppc7d_set_rtc_time(unsigned=20long=20nowtime)
+{
+=20=20=20=20=20=20=20=20struct=20rtc_time=20tm;
+=20=20=20=20=20=20=20=20int=20result;
+
+=20=20=20=20=20=20=20=20spin_lock(&rtc_lock);
+=20=20=20=20=20=20=20=20to_tm(nowtime,=20&tm);
+=20=20=20=20=20=20=20=20result=20=3D=20ds1337_do_command(0,=20DS1337_SET_=
DATE,=20&tm);
+=20=20=20=20=20=20=20=20spin_unlock(&rtc_lock);
+
+=20=20=20=20=20=20=20=20return=20result;
=20}
=20
=20/*=20This=20kernel=20command=20line=20parameter=20can=20be=20used=20to=20=
have=20the=20target
@@=20-1293,6=20+1337,10=20@@
=20=09data8=20|=3D=200x07;
=20=09outb(data8,=20PPC7D_CPLD_LEDS);
=20
+=20=20=20=20=20=20=20=20/*=20Hook=20up=20RTC.=20We=20couldn't=20do=20this=
=20earlier=20because=20we=20need=20the
I2C=20subsystem=20*/
+=20=20=20=20=20=20=20=20ppc_md.set_rtc_time=20=3D=20ppc7d_set_rtc_time;
+=20=20=20=20=20=20=20=20ppc_md.get_rtc_time=20=3D=20ppc7d_get_rtc_time;
+
=20=09pr_debug("%s:=20exit\n",=20__FUNCTION__);
=20}
________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________
^ permalink raw reply
* Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
From: Daniel Ann @ 2005-04-08 8:45 UTC (permalink / raw)
To: linuxppc-embedded
Hey folks,
I seem to have problem getting 1 second right. Board has no RTC so
I've basically NULLed all the todc_XXX functions except
todc_calibrate_decr.
Now question is, what value should I be assigning it to tb_ticks_per_jiffy ?
I was able to dig up some info from the archive, and it read,
=-=-=-FROM ARCHIVE =-=-=-
You must find this value by yourself but a good starting point is your
frequency in Hz (I think)
Example of the code
unsigned int freq = 28000000;
tb_tick_per_jiffy = freq/HZ;
tb_to_us = mulhwu_scale_factor(freq,1000000);
=-=-=-END OF ARCHIVE =-=-=-
I'm fine with working it out myself but where do I start ? My board
has 33MHz OSC, so I've trie freq = 33 * 1000000 (where HZ is defined
100) but it turned out to be little short. I could have just tried few
more trial and error, but I prefer knowing what I'm doing so.. :)
Before I was trying it with 100 * 1000000 which had delays like 10:1.
Now its only about 1.5:1. So, I guess I'm on the right track.... so
can anyone please help me out here?
Also, could anyone spill their brain on mulhwu_scale_factor() ? I've
followed the code and ended up reading what seems to be a assembler.
(Should have paid attention during the lectures :P) Any hint on this ?
Thanks heaps..
Cheers,
--
Daniel
^ permalink raw reply
* [PATCH 2.6.12-rc2 2/2] ppc32: add rtc hooks in PPC7D platform file
From: Chris Elston @ 2005-04-08 9:31 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
This patch adds the hooks into the PPC7D platforms file to
support the DS1337 RTC device as the clock device for the
PPC7D board.
Signed-off-by: Chris Elston <chris.elston@radstone.co.uk>
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
[-- Attachment #2: ppc7d_rtc_hooks.patch --]
[-- Type: application/octet-stream, Size: 2008 bytes --]
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:28:51.000000000 +0100
@@ -68,6 +68,7 @@
#define PPC7D_RST_PIN 17 /* GPP17 */
extern u32 mv64360_irq_base;
+extern spinlock_t rtc_lock;
static struct mv64x60_handle bh;
static int ppc7d_has_alma;
@@ -75,6 +76,11 @@
extern void gen550_progress(char *, unsigned short);
extern void gen550_init(int, struct uart_port *);
+/* FIXME - move to h file */
+extern int ds1337_do_command(int id, int cmd, void *arg);
+#define DS1337_GET_DATE 0
+#define DS1337_SET_DATE 1
+
/* residual data */
unsigned char __res[sizeof(bd_t)];
@@ -1236,6 +1248,38 @@
printk(KERN_INFO "Radstone Technology PPC7D\n");
if (ppc_md.progress)
ppc_md.progress("ppc7d_setup_arch: exit", 0);
+
+}
+
+/* Real Time Clock support.
+ * PPC7D has a DS1337 accessed by I2C.
+ */
+static ulong ppc7d_get_rtc_time(void)
+{
+ struct rtc_time tm;
+ int result;
+
+ spin_lock(&rtc_lock);
+ result = ds1337_do_command(0, DS1337_GET_DATE, &tm);
+ spin_unlock(&rtc_lock);
+
+ if (result == 0)
+ result = mktime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
+
+ return result;
+}
+
+static int ppc7d_set_rtc_time(unsigned long nowtime)
+{
+ struct rtc_time tm;
+ int result;
+
+ spin_lock(&rtc_lock);
+ to_tm(nowtime, &tm);
+ result = ds1337_do_command(0, DS1337_SET_DATE, &tm);
+ spin_unlock(&rtc_lock);
+
+ return result;
}
/* This kernel command line parameter can be used to have the target
@@ -1293,6 +1337,10 @@
data8 |= 0x07;
outb(data8, PPC7D_CPLD_LEDS);
+ /* Hook up RTC. We couldn't do this earlier because we need the I2C subsystem */
+ ppc_md.set_rtc_time = ppc7d_set_rtc_time;
+ ppc_md.get_rtc_time = ppc7d_get_rtc_time;
+
pr_debug("%s: exit\n", __FUNCTION__);
}
^ permalink raw reply
* [PATCH 2.6.12-rc2 1/2] ppc32: fix for misreported SDRAM size on Radstone PPC7D platform
From: Chris Elston @ 2005-04-08 9:31 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
This patch fixes the SDRAM output from /proc/cpuinfo.
The previous code assumed that there was only one bank
of SDRAM, and that the size in the memory configuration
register was the total size.
Signed-off-by: Chris Elston <chris.elston@radstone.co.uk>
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
[-- Attachment #2: ppc7d_sdram_size.patch --]
[-- Type: application/octet-stream, Size: 2015 bytes --]
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.c 2005-04-07 12:28:51.000000000 +0100
@@ -253,6 +259,8 @@
u8 val1, val2;
static int flash_sizes[4] = { 64, 32, 0, 16 };
static int flash_banks[4] = { 4, 3, 2, 1 };
+ static int sdram_bank_sizes[4] = { 128, 256, 512, 1 };
+ int sdram_num_banks = 2;
static char *pci_modes[] = { "PCI33", "PCI66",
"Unknown", "Unknown",
"PCIX33", "PCIX66",
@@ -279,13 +287,17 @@
(val1 == PPC7D_CPLD_MB_TYPE_PLL_100) ? 100 :
(val1 == PPC7D_CPLD_MB_TYPE_PLL_64) ? 64 : 0);
+ val = inb(PPC7D_CPLD_MEM_CONFIG);
+ if (val & PPC7D_CPLD_SDRAM_BANK_NUM_MASK) sdram_num_banks--;
+
val = inb(PPC7D_CPLD_MEM_CONFIG_EXTEND);
- val1 = val & PPC7D_CPLD_SDRAM_BANK_SIZE_MASK;
- seq_printf(m, "SDRAM\t\t: %d%c",
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_128M) ? 128 :
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_256M) ? 256 :
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_512M) ? 512 : 1,
- (val1 == PPC7D_CPLD_SDRAM_BANK_SIZE_1G) ? 'G' : 'M');
+ val1 = (val & PPC7D_CPLD_SDRAM_BANK_SIZE_MASK) >> 6;
+ seq_printf(m, "SDRAM\t\t: %d banks of %d%c, total %d%c",
+ sdram_num_banks,
+ sdram_bank_sizes[val1],
+ (sdram_bank_sizes[val1] < 128) ? 'G' : 'M',
+ sdram_num_banks * sdram_bank_sizes[val1],
+ (sdram_bank_sizes[val1] < 128) ? 'G' : 'M');
if (val2 & PPC7D_CPLD_MB_TYPE_ECC_FITTED_MASK) {
seq_printf(m, " [ECC %sabled]",
(val2 & PPC7D_CPLD_MB_TYPE_ECC_ENABLE_MASK) ? "en" :
--- linux-2.6.12-rc2/arch/ppc/platforms/radstone_ppc7d.h 2005-04-07 12:31:43.000000000 +0100
+++ linux-2.6.12-rc2-cde/arch/ppc/platforms/radstone_ppc7d.h 2005-04-07 12:28:51.000000000 +0100
@@ -240,6 +240,7 @@
#define PPC7D_CPLD_FLASH_CNTL 0x086E
/* MEMORY_CONFIG_EXTEND */
+#define PPC7D_CPLD_SDRAM_BANK_NUM_MASK 0x02
#define PPC7D_CPLD_SDRAM_BANK_SIZE_MASK 0xc0
#define PPC7D_CPLD_SDRAM_BANK_SIZE_128M 0
#define PPC7D_CPLD_SDRAM_BANK_SIZE_256M 0x40
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-08 10:13 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050407171026.GO3396@smtp.west.cox.net>
> I think you're the only person building a zImage for a 32bit kernel with
> a 64bit toolchain for MULTIPLATFORM, yes. :)
I should move to 64bits :)
> This is a valid problem, however. Does the following also work for you?
It partly works (correct the problem with disable_6xx_mmu)
but i still have to the following for resolving __flush_disable_L1
I changed the makefile in arch/ppc/kernel to have this :
obj-$(CONFIG_POWER4) += cpu_setup_power4.o
into :
obj-$(CONFIG_POWER4) += l2cr.o cpu_setup_power4.o
Jerome Glisse
^ permalink raw reply
* Re: FCC Ethernet startup crash
From: Stefan Nickl @ 2005-04-08 10:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050407163607.GN3396@smtp.west.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Thu, 2005-04-07 at 09:36 -0700, Tom Rini wrote:
> > The patch Stefan Nickl gave to me works perfectly, and all it does is
> > basically move the fcc_restart.
> > The kernel was still calling fcc_restart twiche per FCC at startup (one
> > time on init_fcc_startup, and then again in fcc_open), now it just calls
> > it twice in fcc_open. Seems to work.
>
> Would someone please post what's needed vs current'ish 2.6 so we can get
> the proper fix up & in? :) With the Signed-off-by & all that.. Thanks.
I took a little longer because I was not happy with the simple
cut'n'paste version. I believe the actual problem is that fcc_restart()
mustn't be called before netif_start_queue(). So the original version
only shortens the race period, it does not actually resolve it.
Unfortunately I'm deprived of suitable hardware as the focus of my work
has shifted in the last months, so I urge everyone out there to give it
a try.
Signed-off-by: Stefan Nickl <Stefan.Nickl@kontron.com>
--
Stefan Nickl
Kontron Modular Computers
[-- Attachment #2: fcc_enet_startup_crash_v2.patch --]
[-- Type: text/x-patch, Size: 1828 bytes --]
--- linux-2.5/arch/ppc/8260_io/fcc_enet.c.bak 2005-04-08 09:37:40.000000000 +0200
+++ linux-2.5/arch/ppc/8260_io/fcc_enet.c 2005-04-08 12:01:55.000000000 +0200
@@ -2158,16 +2158,6 @@ init_fcc_startup(fcc_info_t *fip, struct
*(volatile uint *)(BCSR_ADDR + 12) &= ~BCSR3_FETHIEN2;
*(volatile uint *)(BCSR_ADDR + 12) |= BCSR3_FETH2_RST;
#endif
-
-#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
- /* start in full duplex mode, and negotiate speed
- */
- fcc_restart (dev, 1);
-#else
- /* start in half duplex mode
- */
- fcc_restart (dev, 0);
-#endif
}
#ifdef CONFIG_USE_MDIO
@@ -2372,24 +2362,28 @@ fcc_enet_open(struct net_device *dev)
fep->sequence_done = 0;
fep->link = 0;
- if (fep->phy) {
- fcc_restart(dev, 0); /* always start in half-duplex */
- mii_do_cmd(dev, fep->phy->ack_int);
- mii_do_cmd(dev, fep->phy->config);
- mii_do_cmd(dev, phy_cmd_config); /* display configuration */
- while(!fep->sequence_done)
- schedule();
-
- mii_do_cmd(dev, fep->phy->startup);
- netif_start_queue(dev);
- return 0; /* Success */
- }
- return -ENODEV; /* No PHY we understand */
+ if (!fep->phy)
+ return -ENODEV; /* No PHY we understand */
+
+ mii_do_cmd(dev, fep->phy->ack_int);
+ mii_do_cmd(dev, fep->phy->config);
+ mii_do_cmd(dev, phy_cmd_config); /* display configuration */
+ while(!fep->sequence_done)
+ schedule();
+
+ mii_do_cmd(dev, fep->phy->startup);
#else
fep->link = 1;
- fcc_restart(dev, 0); /* always start in half-duplex */
- netif_start_queue(dev);
- return 0; /* Always succeed */
#endif /* CONFIG_USE_MDIO */
+
+ netif_start_queue(dev);
+
+#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
+ fcc_restart (dev, 1); /* start in full duplex mode */
+#else
+ fcc_restart (dev, 0); /* start in half duplex mode */
+#endif
+
+ return 0; /* Always succeed */
}
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Leigh Brown @ 2005-04-08 11:36 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050406185049.GF3396@smtp.west.cox.net>
Tom Rini said:
> On Wed, Apr 06, 2005 at 03:47:13AM +0200, Christian wrote:
>> Tom Rini wrote:
>> > Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
>> > command-line works? Thanks.
>>
>> i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as
>> Sven
>> sugggested), but the scsi errors did not went away :(
>>
>> on a side note, and perhaps totally unrelated: i always have
>> PROC_PREPRESIDUAL=y in my .config, but i never had /proc/residual as
>> promised from the help text.
>
> Odd. I thought that only happened if you had no residual data at all
> (which can happen on Powerstacks, esp if netbooting the kernel). But in
> that case the new code shouldn't be hit at all. Leigh?
Hi, I'm back from my holidays, and have had a look at this. As I spent
lots of time understanding the horrendous mess that was
prep_pcibios_fixup(), I'd be loath to back out the changes I made
(especially as they work so well for me ;-) ).
It turns out that prep_pib_init() is the culprit. Although it would
appear to be coded for the non-openpic case, it obviously doesn't work.
The old version of prep_pcibios_fixup() only called it if there is an
openpic on the machine. We can restore that behaviour with the
following patch:
--- prep_pci.c.orig 2005-04-08 11:49:25.743718088 +0000
+++ prep_pci.c 2005-04-08 12:23:00.541422280 +0000
@@ -1245,8 +1245,13 @@
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
}
- /* Setup the Winbond or Via PIB */
- prep_pib_init();
+ /* Setup the Winbond or Via PIB - prep_pib_init() is coded for
+ * the non-openpic case, but it breaks (at least) the Utah
+ * (Powerstack II Pro4000), so only call it if we have an
+ * openpic.
+ */
+ if (have_openpic)
+ prep_pib_init();
}
static void __init
I've no idea even what machines would be affected by this, but it
fixes Sven's problem and restores the old behaviour, so that
can't be bad.
I guess fixing prep_pib_init() would be the better solution but
I wouldn't know where to start. If this band-aid is good enough
I can submit a proper patch, if you like.
Cheers,
Leigh.
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-08 13:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <JPEALJAFNGDDLOPNDIEEAEHJDCAA.joakim.tjernlund@lumentis.se>
On Apr 8, 2005, at 4:01 AM, Joakim Tjernlund wrote:
> I was looking at the DTLB Error excetion(p. 7-15) in the MPC860 User's
> Manual. There
Yeah, well what the manual says and what really happens seems to be
two different things.
> .... There is also a 8xx specific test with bit 3(0x1000000) in
> fault.c but
> bit 3 is always zero according the MPC860 Manual for a DTLB Error.
Read the comment. It really happens. I spent lots and lots of time
sorting
out how the 8xx works, setting up precise test cases and examining the
results. Stop reading the manual too closely and create test cases to
see what exactly happens.
> Then we end up with bit 1(invalid TLB) and bit 6(store operation) set.
> Maybe one
> could make the DTLB Error handler test if bit 1 is set and then branch
> to
> DataAccess and then deal with the problem in fault.c?
No. That is adding even more code to the "normal" path. The TLB miss
should simply take a value from memory and load it into the TLB.
Nothing
more. It should emulate what a hardware implementation would do ...
eight instructions, no branches, if done properly :-)
Thanks.
-- Dan
^ permalink raw reply
* Question about problem with serial line behavior
From: nick caruso @ 2005-04-08 13:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi
We are bringing up linux on a custom MPC5200 board based on the Lite5200 design published by Freescale.
We're using u-boot as the boot loader. We run the console serial line at 115200 Baud.
On some boards, the serial console spews gibberish *after* u-boot has started linux. On other boards, with exactly the same software, this does not happen.
Linux boots fine in both cases; we can telnet in to the boards and everything seems fine (the console port is even configured correctly according to linux).
But looking at the output on the console serial line with a scope, we can see that the baud rate seems to be set much higher - higher in fact than our line drivers can handle.
To re-iterate, the u-boot loader works fine at 115200 on these boards; it's only after we start the linux kernel that the output becomes gibberish, And the same software loaded on other boards does not exhibit this behavior. The other boards are identical in design to the failing boards.
Does anyone have any suggestions as to what might be going wrong here?
The linux kernel we're using is based on a 2.6.7 kernel.
any help would be greatly appreciated!
thanks, and best regards,
Nick Caruso
ncaruso@irobot.com
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Kumar Gala @ 2005-04-08 14:08 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <20050408082635.GB4992@iram.es>
On Apr 8, 2005, at 3:26 AM, Gabriel Paubert wrote:
> On Wed, Apr 06, 2005 at 04:33:14PM -0500, Kumar Gala wrote:
> > Here is a version that works if CONFIG_PTE_64BIT is defined.=A0 If =
we
> > like this, I can simplify the pte_update so we dont need the=20
> (unsigned
> > long)(p+1) - 4) trick anymore.=A0 Let me know.
> >
> > - kumar
> >
> > #ifdef CONFIG_PTE_64BIT
> > static inline unsigned long long pte_update(pte_t *p, unsigned long=20=
> clr,
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long set)
> > {
> >=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long long old;
> >=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long tmp;
> >
> >=A0=A0=A0=A0=A0=A0=A0=A0 __asm__ __volatile__("\
> > 1:=A0=A0=A0=A0=A0 lwarx=A0=A0 %L0,0,%4\n\
> >=A0=A0=A0=A0=A0=A0=A0=A0 lwzx=A0=A0=A0 %0,0,%3\n\
> >=A0=A0=A0=A0=A0=A0=A0=A0 andc=A0=A0=A0 %1,%L0,%5\n\
> >=A0=A0=A0=A0=A0=A0=A0=A0 or=A0=A0=A0=A0=A0 %1,%1,%6\n\
> >=A0=A0=A0=A0=A0=A0=A0=A0 stwcx.=A0 %1,0,%4\n\
> >=A0=A0=A0=A0=A0=A0=A0=A0 bne-=A0=A0=A0 1b"
> >=A0=A0=A0=A0=A0=A0=A0=A0 : "=3D&r" (old), "=3D&r" (tmp), "=3Dm" (*p)
> >=A0=A0=A0=A0=A0=A0=A0=A0 : "r" (p), "r" ((unsigned long)(p) + 4), "r" =
(clr), "r"=20
> (set),
> > "m" (*p)
>
> Are you sure of your pointer arithmetic? I believe that
> you'd rather want to use (unsigned char)(p)+4. Or even better:
Realize that I'm converting the pointer to an int, so its not exactly=20
normal pointer math. Was stick with the pre-existing stye.
>
> :"r" (p), "b" (4), "r" (clr), "r" (set)
>
> and change the first line to:=A0 lwarx %L0,%4,%3.
>
> Even more devious, you don't need the %4 parameter:
>
> =A0=A0=A0=A0=A0=A0=A0 li %L0,4
> =A0=A0=A0=A0=A0=A0=A0 lwarx %L0,%L0,%3
>
> since %L0 cannot be r0. This saves one register.
Actually the compiler effective does this for me. If you look at the=20
generated asm, the only additional instruction is an 'addi' and some=20
'mr' to handle getting things in the correct registers for the return. =20=
Not really sure if there is much else to do to optimize this.
> >=A0=A0=A0=A0=A0=A0=A0=A0 : "cc" );
>
> On PPC, I always prefer saying cr0 over cc. Maybe it's just
> me, but it's the canonical register name in the architecture.
Was sticking with the style of what already existed, but I agree that=20
cr is more natural to read than cc.
- kumar
^ permalink raw reply
* Re: Unhandled relocation of type 11
From: Joshua Lamorie @ 2005-04-08 14:08 UTC (permalink / raw)
To: Joshua Lamorie; +Cc: Wolfgang Grandegger, rtai, linuxppc-embedded
In-Reply-To: <425541C8.6060408@xiphos.ca>
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
Yes, this fix appeared to work. It looks like there are just four
14-bit references:
ppc_ftoui.S:56: blt __fixsfsi /* return directly
from there */
ppc_ftoui.S:61: blt __fixsfsi /* return directly
form there */
ppc_dtoui.S:63: blt __fixdfsi
ppc_dtoui.S:73: blt __fixdfsi
I've sent an email to the sourceforge maintainer, but I haven't heard
anything yet. It's a great library, it greatly improves FP
performance. Anyone else been using it? Any problems?
My fix is attached.
Joshua
--
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
[-- Attachment #2: fptoui_module.patch --]
[-- Type: text/plain, Size: 2514 bytes --]
--- perflibs.orig/fpopt/ppc_dtoui.S 2003-12-12 15:38:02.000000000 -0500
+++ perflibs/fpopt/ppc_dtoui.S 2005-04-08 10:03:19.629210784 -0400
@@ -53,14 +53,26 @@ function_prolog(__fixunsdfsi)
/* For negative numbers, just convert to signed integer */
or. r3,r3,r3
- blt __fixdfsi /* return directly from there */
+#if defined(__KERNEL__) && defined(MODULE)
+ bge positive
+ bl __fixdfsi /* return directly from there */
+#else
+ blt __fixdfsi
+#endif
+positive:
rlwinm r8,r3,12,0x000007FF /* extract exponent */
/* For numbers less than maximum positive signed integer, convert normally */
cmpwi r8, 0x041e
- blt __fixdfsi /* return directly form there */
+#if defined(__KERNEL__) && defined(MODULE)
+ bge overmax
+ bl __fixdfsi /* return directly form there */
+#else
+ blt __fixdfsi
+#endif
/* Create stack frame, just to save link register! */
+overmax:
mflr r0 /* save link register in caller's stack */
stw r0,4(r1)
stwu r1,-STACKSIZE(r1) /* set up stack frame to hold saved regs */
--- perflibs.orig/fpopt/ppc_ftoui.S 2003-12-12 15:38:02.000000000 -0500
+++ perflibs/fpopt/ppc_ftoui.S 2005-04-08 10:06:46.155813968 -0400
@@ -53,14 +53,26 @@ function_prolog(__fixunssfsi)
/* For negative numbers, just convert to signed integer */
or. r3,r3,r3
- blt __fixsfsi /* return directly from there */
+#if defined(__KERNEL__) && defined(MODULE)
+ bge positive
+ bl __fixsfsi /* return directly from there */
+#else
+ blt __fixsfsi
+#endif
+positive:
rlwinm r8,r3,9,0x000000FF /* extract exponent */
/* For numbers less than maximum positive signed integer, convert normally */
cmpwi r8, 0x009e
- blt __fixsfsi /* return directly form there */
+#if defined(__KERNEL__) && defined(MODULE)
+ bge overmax
+ bl __fixsfsi /* return directly form there */
+#else
+ blt __fixsfsi
+#endif
/* Create stack frame, just to save link register! */
+overmax:
mflr r0 /* save link register in caller's stack */
stw r0,4(r1)
stwu r1,-STACKSIZE(r1) /* set up stack frame to hold saved regs */
^ permalink raw reply
* cross-compiling under cygwin?
From: Robert P. J. Day @ 2005-04-08 14:13 UTC (permalink / raw)
To: Embedded PPC Linux list
i've just had a request from a colleague who wants to do all the
cross-compilation for our 8xx board on a windows box, rather than
linux.
there was talk of cygwin, and kdevelop as well. i'm still parsing
the rest of the email but is there a canonical URL that discusses
working in the windows environment?
i'm just about to head over to denx.de to see what i can find.
thanks for any pointers.
rday
^ permalink raw reply
* RE: 8xx v2.6 TLB problems and suggested workaround
From: Joakim Tjernlund @ 2005-04-08 14:29 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <86dfdfc8a80cde21c19c09403139ae3b@embeddededge.com>
> -----Original Message-----
> From: Dan Malek [mailto:dan@embeddededge.com]
>
> On Apr 8, 2005, at 4:01 AM, Joakim Tjernlund wrote:
>
> > I was looking at the DTLB Error excetion(p. 7-15) in the MPC860 User's
> > Manual. There
>
> Yeah, well what the manual says and what really happens seems to be
> two different things.
Yep, the manual really sucks sometimes. The manual errata is huge
so it would be more than welcome if Freesacle actually updated the
maunal with the errata items.
>
> > .... There is also a 8xx specific test with bit 3(0x1000000) in
> > fault.c but
> > bit 3 is always zero according the MPC860 Manual for a DTLB Error.
>
> Read the comment. It really happens. I spent lots and lots of time
> sorting
> out how the 8xx works, setting up precise test cases and examining the
> results. Stop reading the manual too closely and create test cases to
> see what exactly happens.
OK, fine. Just wanted to hear that.
>
> > Then we end up with bit 1(invalid TLB) and bit 6(store operation) set.
> > Maybe one
> > could make the DTLB Error handler test if bit 1 is set and then branch
> > to
> > DataAccess and then deal with the problem in fault.c?
>
> No. That is adding even more code to the "normal" path. The TLB miss
> should simply take a value from memory and load it into the TLB.
> Nothing
> more. It should emulate what a hardware implementation would do ...
> eight instructions, no branches, if done properly :-)
I was talking about the TLB Error handler. The TLB Miss handler should be kept as small
as possible.
Any ideas on how to fix the problem Marcelo reported?
Jocke
>
> Thanks.
>
>
> -- Dan
>
^ permalink raw reply
* [PATCH 2.6.12-rc2]: ppc32: Fix a problem with NTP on !(chrp||gemini)
From: Tom Rini @ 2005-04-08 14:38 UTC (permalink / raw)
To: Andrew Morton, Kernel Mailing List, linuxppc-dev; +Cc: Giovambattista Pulcini
The following problem was found by Giovambattista Pulcini
<gpulcini@swintel.it>, who also provided a partial patch, and this has
been verified by our time guru Gabriel Paubert <paubert@iram.es>.
The problem is that in do_settimeofday() we always set time_state to
TIME_ERROR and except on two platforms, never re-set it. This meant
that ntp_gettime() and ntp_adjtime() always returned TIME_ERROR,
incorrectly. Based on Gabriel's analysis, time_state is used for
leap-second processing, and ppc shouldn't be mucking with it.
From: Giovambattista Pulcini <gpulcini@swintel.it>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- 1.37/arch/ppc/kernel/time.c 2005-01-20 22:02:08 -07:00
+++ edited/arch/ppc/kernel/time.c 2005-04-08 07:30:46 -07:00
@@ -272,7 +272,6 @@
time_adjust = 0; /* stop active adjtime() */
time_status |= STA_UNSYNC;
- time_state = TIME_ERROR; /* p. 24, (a) */
time_maxerror = NTP_PHASE_LIMIT;
time_esterror = NTP_PHASE_LIMIT;
write_sequnlock_irqrestore(&xtime_lock, flags);
--- 1.11/arch/ppc/platforms/chrp_time.c 2005-01-25 14:50:14 -07:00
+++ edited/arch/ppc/platforms/chrp_time.c 2005-04-08 07:30:53 -07:00
@@ -115,8 +115,6 @@
chrp_cmos_clock_write(save_control, RTC_CONTROL);
chrp_cmos_clock_write(save_freq_select, RTC_FREQ_SELECT);
- if ( (time_state == TIME_ERROR) || (time_state == TIME_BAD) )
- time_state = TIME_OK;
spin_unlock(&rtc_lock);
return 0;
}
--- 1.17/arch/ppc/platforms/gemini_setup.c 2005-03-13 16:29:43 -07:00
+++ edited/arch/ppc/platforms/gemini_setup.c 2005-04-08 07:30:56 -07:00
@@ -433,9 +433,6 @@
/* done writing */
gemini_rtc_write(reg, M48T35_RTC_CONTROL);
- if ((time_state == TIME_ERROR) || (time_state == TIME_BAD))
- time_state = TIME_OK;
-
return 0;
}
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-08 14:39 UTC (permalink / raw)
To: Stefan Nickl, Tom Rini; +Cc: linuxppc-embedded
I'm not sure what is going on, but that patch causes me to get "eth0: tx
queue full!." messages as soon as I try to use the ethernet
(Same thing happened if I just tried to remove the fcc_restart from
init_fcc_startup)
> -----Original Message-----
> From: Stefan Nickl [mailto:Stefan.Nickl@kontron.com]=20
> Sent: Friday, April 08, 2005 05:49
> To: Tom Rini
> Cc: Rune Torgersen; linuxppc-embedded
> Subject: Re: FCC Ethernet startup crash
>=20
> On Thu, 2005-04-07 at 09:36 -0700, Tom Rini wrote:
> > > The patch Stefan Nickl gave to me works perfectly, and=20
> all it does is
> > > basically move the fcc_restart.
> > > The kernel was still calling fcc_restart twiche per FCC=20
> at startup (one
> > > time on init_fcc_startup, and then again in fcc_open),=20
> now it just calls
> > > it twice in fcc_open. Seems to work.
> >=20
> > Would someone please post what's needed vs current'ish 2.6=20
> so we can get
> > the proper fix up & in? :) With the Signed-off-by & all=20
> that.. Thanks.
>=20
> I took a little longer because I was not happy with the simple
> cut'n'paste version. I believe the actual problem is that=20
> fcc_restart()
> mustn't be called before netif_start_queue(). So the original version
> only shortens the race period, it does not actually resolve it.
>=20
> Unfortunately I'm deprived of suitable hardware as the focus=20
> of my work
> has shifted in the last months, so I urge everyone out there=20
> to give it
> a try.
>=20
> Signed-off-by: Stefan Nickl <Stefan.Nickl@kontron.com>
>=20
> --=20
> Stefan Nickl
> Kontron Modular Computers
>=20
>=20
^ permalink raw reply
* Re: PCI Arbiter on PPC440GX?
From: Ralph Siemsen @ 2005-04-08 14:27 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-dev
In-Reply-To: <0007F077BB3476449151699150E8FEA20592AF@exchange.tsi-telsys.com>
Sanjay Bajaj wrote:
> How do I enable/disable PCI Arbiter on PPC440GX?
See the UserManual for all the details... but the arbiter enable/disable
is a strapping option. If you do not have a serial boot prom, then the
arbiter is off by default. You can override this in your bootloader by
poking a register. Seach the manual for "PAE" (Pci Arbiter Enable).
The register is SDR0_XCR, bit #0 (page 347).
-R
^ 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