* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-09-26 19:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <Pine.LNX.4.58.0709261502590.4465@gandalf.stny.rr.com>
Hello.
Steven Rostedt wrote:
> Tony,
> I'm about to release a new -rt patch based on -rc8. This patch series
> blew up totally in trying to get it applied. I'm leaving it out, so after
> I release the next series, could you update these patches.
No wonder here: the -rt patch already has much of this code since around
2.6.21. They have been submitted by me, mostly... and this patchset is
against the Linus' tree.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Steven Rostedt @ 2007-09-26 19:44 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <46FAB56E.8080509@ru.mvista.com>
--
On Wed, 26 Sep 2007, Sergei Shtylyov wrote:
> Hello.
>
> Steven Rostedt wrote:
> > Tony,
>
> > I'm about to release a new -rt patch based on -rc8. This patch series
> > blew up totally in trying to get it applied. I'm leaving it out, so after
> > I release the next series, could you update these patches.
>
> No wonder here: the -rt patch already has much of this code since around
> 2.6.21. They have been submitted by me, mostly... and this patchset is
> against the Linus' tree.
That would explain it ;-)
I was searching the linux-rt-users mailing list for any patches, and
pulled in any that looked legit. These happen to in that mailing list too.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Thomas Gleixner @ 2007-09-26 19:58 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, Paul Mackerras, Realtime Kernel
In-Reply-To: <Pine.LNX.4.58.0709261543080.5123@gandalf.stny.rr.com>
On Wed, 2007-09-26 at 15:44 -0400, Steven Rostedt wrote:
> > No wonder here: the -rt patch already has much of this code since around
> > 2.6.21. They have been submitted by me, mostly... and this patchset is
> > against the Linus' tree.
>
> That would explain it ;-)
>
> I was searching the linux-rt-users mailing list for any patches, and
> pulled in any that looked legit. These happen to in that mailing list too.
I'll sort that out along with the other hrt updates.
tglx
^ permalink raw reply
* RE: git files from secret lab
From: Mead, Joseph @ 2007-09-26 20:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40709260800o49cc9816j642358a14731d08f@mail.gmail.com>
>> Hi,
>>
>> I'm trying to download the xilinx patches from Grant's git
repository,
>> but don't quite understand what I am doing.
>>
>> I cloned the tree from Linus' tree
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> (this worked fine)
>>
>> cd linux-2.6
>What version of git are you running (git --version). That tree is
>using the virtual hosting feature of newer versions of git. You need
>to be running at least version 1.5.
>Cheers,
>g.
Thanks, that was the problem...
^ permalink raw reply
* RE: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Rune Torgersen @ 2007-09-26 20:32 UTC (permalink / raw)
To: Scott Wood, Dan Malek; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F8101E.1050000@freescale.com>
> From: Scott Wood
> Maybe that's how it was, but the current code initializes it (more or
> less) directly with IMAP_ADDR, which also gets fed into ioremap.
>=20
> One of the two has got to be wrong.
arch/ppc maps the immr area 1:1 into kernel memory, so ioremap and
physical are the same.
See arch/ppc/syslib/m8260_setup.c, line 208 (function m8260_map_io)
Here quoted:
arch/ppc/syslib/m8260_setup.c
196 /* Map the IMMR, plus anything else we can cover
197 * in that upper space according to the memory controller
198 * chip select mapping. Grab another bunch of space
199 * below that for stuff we can't cover in the upper.
200 */
201 static void __init
202 m8260_map_io(void)
203 {
204 uint addr;
205
206 /* Map IMMR region to a 256MB BAT */
207 addr =3D (cpm2_immr !=3D NULL) ? (uint)cpm2_immr : =
CPM_MAP_ADDR;
208 io_block_mapping(addr, addr, 0x10000000, _PAGE_IO);
209
210 /* Map I/O region to a 256MB BAT */
211 io_block_mapping(IO_VIRT_ADDR, IO_PHYS_ADDR, 0x10000000,
_PAGE_IO);
212 }
^ permalink raw reply
* [PATCH] [serial gadget] Disable endpoints on unload
From: Vitaly Bordug @ 2007-09-26 20:36 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev
After Serial gadget is being unloaded, neither serial itself, nor other
gadget stuff can be loaded subsequently.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
drivers/usb/gadget/serial.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index ce4d2e0..594284a 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -1487,6 +1487,12 @@ static void /* __init_or_exit */ gs_unbind(struct usb_gadget *gadget)
dev->dev_ctrl_req = NULL;
}
gs_free_ports(dev);
+ if (dev->dev_notify_ep)
+ usb_ep_disable(dev->dev_notify_ep);
+ if (dev->dev_in_ep)
+ usb_ep_disable(dev->dev_in_ep);
+ if (dev->dev_out_ep)
+ usb_ep_disable(dev->dev_out_ep);
kfree(dev);
set_gadget_data(gadget, NULL);
}
^ permalink raw reply related
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-26 20:41 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0368C44B@ismail.innsys.innovsys.com>
On Wed, Sep 26, 2007 at 03:32:29PM -0500, Rune Torgersen wrote:
> > From: Scott Wood
> > Maybe that's how it was, but the current code initializes it (more or
> > less) directly with IMAP_ADDR, which also gets fed into ioremap.
> >
> > One of the two has got to be wrong.
>
> arch/ppc maps the immr area 1:1 into kernel memory, so ioremap and
> physical are the same.
> See arch/ppc/syslib/m8260_setup.c, line 208 (function m8260_map_io)
We were talking about 8xx, not 82xx -- is it always identity mapped there?
If so, then why bother with the ioremap in immr_map_size() in
arch/ppc/8xx_io/commproc.c? And why compare the result from ioremap() with
a raw identity-mapped address?
-Scott
^ permalink raw reply
* Re: [PATCH 0/3] PowerPC: Add cpu_setup functionality to 44x platform
From: Josh Boyer @ 2007-09-26 21:12 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070921144149.GA4150@ru.mvista.com>
On Fri, 21 Sep 2007 18:41:49 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> This patchset adds cpu_setup functionality to PowerPC 44x,
> moves FPU init to cpu_setup callback and adds 440EPx/440GRx
> incorrect write to DDR SDRAM errata workaround.
This set looks pretty good to me. Aside from the slight oddity of
adding an essentially empty file in the first patch. But it makes
things nicely bisectable and I asked for it to be done that way.
Unless someone has objections, I'll probably pull this in soon after I
test a bit.
josh
^ permalink raw reply
* Re: changing the EDLK components
From: Wolfgang Denk @ 2007-09-26 23:20 UTC (permalink / raw)
To: Murat Artun; +Cc: linuxppc-embedded
In-Reply-To: <4e5a3720709260725x6d2e9faemc6a6053379610df8@mail.gmail.com>
In message <4e5a3720709260725x6d2e9faemc6a6053379610df8@mail.gmail.com> you wrote:
>
> I want to learn the way of building a GNU Automake project and adding
> it into ELDK. This could be needed because the current version of an
> ELDK component is old to meet the requirements or a library which is
> not an ELDK component is to be used in our ppc system.
In principle, this is a pretty straightforward procedure: you
download the source RPM (for example, from the Fedora 7
distribution), and use the "rpmbuild" command on the native syustem
(running with root file system mounted over NFS or on a local
harddisk) to build the stuff. For example:
$ rpmbuild --rebuild automake17-1.7.9-8.src.rpm
That's in proinciple. In reality, you will soon learn that the
package has a lot of build dependencies, which are not exactly
trivial to resolve, as some of them are circular. You can try and find
what's really needed (and not included with the ELDK) by running
$ rpmbuild --rebuild --nodeps automake17-1.7.9-8.src.rpm
but this is just tof ind out how many othe rpackages youw ill need to
build before...
> As now, I need to upgrade an ELDK component. Namely, I need version
> 0.9.8 of OpenSSL, where latest ELDK release has OpenSSL with version
> 0.9.7f. I want to learn if it is necessary for me to follow the same
You don't need a native version of automake for this, as builing is
done in the cross environment, and we assume you have automake
installed on your build host.
> procedure stated in documentation in section "3.7. Rebuilding ELDK
> Components". If this is the case, could anyone point me to resources
> about how to prepare source rpms from an Automake project to prepare
I don't understand why you mention automake here. It is completely
unrelated.
> the source rpm of version 0.9.8 of OpenSSL? Of course building the new
> version of the component and placing everything by hand is always a
> solution, but I want to understand the clean way of doing this.
The clean way is to adjust the ELDK buld system for the new version.
This is usually a non-trivial job. By doing it you will start to
admire what ELDK gives you and understand at least a bit of how much
effort is built into it - and you get it all completely for free...
Alternatively, you can just wait for ELDK 4.2, which will include
openssl-0.9.8b-12
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That Microsoft, the Trabant of the operating system world, may be
glancing over the Berlin Wall at the Audis and BMWs and Mercedes. In
their own universe Trabants and Ladas were mainstream too...
-- Evan Leibovitch
^ permalink raw reply
* really old glibc on 8xx or 403 with bleeding-edge kernel - anyone care?
From: Paul Mackerras @ 2007-09-26 23:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-embedded
Since about May 2001, we have put two AT_IGNOREPPC entries at the
beginning of the ELF auxiliary vector. The reason for this is that
glibc prior to April 2001 rounded up the address of the base of the
aux vector to a multiple of 16. I think we can now get rid of the
AT_IGNOREPPC entries.
Well, in fact what old glibc did was a little more complex than that.
It worked out the standard aux vector base (i.e. the address of the
word after the end of the environment pointers), and then chose either
that or that address rounded up to a multiple of 16 bytes. The way it
chose was by checking the word at the rounded address - if it was more
than 16 it used the standard base address, otherwise it used the
rounded address.
So the way the AT_IGNOREPPC hack worked was by putting 4 words (two
aux vector entries) at the beginning of the aux vector that all
contained the value 22 (AT_IGNOREPPC). That made the old glibc code
choose the standard aux vector base address.
However, what comes after that is an AT_DCACHEBSIZE (19) entry and an
AT_ICACHEBSIZE (20) entry. Thus, as long as the data cache blocksize
and the instruction cache blocksize are greater than 16, these two
entries will serve just as well as the AT_IGNOREPPC entries at making
old glibc choose the standard aux vector base address.
The only CPUs that we support with cache line sizes of 16 bytes or
less are the 8xx family and the 403 family. So my question is, does
anyone care about running ancient userland binaries (from 2001 or
earlier) on 8xx or 403 with future kernels (2.6.x for x >= 24)?
If not then we can remove the AT_IGNOREPPC aux vector entries.
Paul.
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Benjamin Herrenschmidt @ 2007-09-27 1:59 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel,
Steven Rostedt
In-Reply-To: <46FAB56E.8080509@ru.mvista.com>
On Wed, 2007-09-26 at 23:39 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Steven Rostedt wrote:
> > Tony,
>
> > I'm about to release a new -rt patch based on -rc8. This patch series
> > blew up totally in trying to get it applied. I'm leaving it out, so after
> > I release the next series, could you update these patches.
>
> No wonder here: the -rt patch already has much of this code since around
> 2.6.21. They have been submitted by me, mostly... and this patchset is
> against the Linus' tree.
Proper approach is to rip off what is altready in -rt there and replace
it with Tony patch set.
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-27 2:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> Hi,
>
> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> (ps3fb):
> [1] ps3av: eliminate unneeded temporary variables
> [2] ps3av: eliminate PS3AV_DEBUG
> [3] ps3av: use PS3 video mode ids in autodetect code
> [4] ps3av: treat DVI-D like HDMI in autodetect
> [5] ps3av: add autodetection for VESA modes
> [6] ps3av: add quirk database for broken monitors
> [7] ps3av: remove unused ps3av_set_mode()
> [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
>
> Please review, and queue for 2.6.24 if they're ok. Thanks!
>
> Question: As several DVI-D displays advertise they support 1080i modes while
> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> better than 1080i anyway. What do you think?
Definitely. If the autodetection fails Linux is basically unusable on
PS3 unless you hack the kernel sources and build your own kboot and
otheros.bld - not entirely trivial for novice users. So it's pretty
important that it works 100%.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: David Gibson @ 2007-09-27 2:45 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <69f1ad37eec293a4c4616d04c8400ca4@bga.com>
On Wed, Sep 26, 2007 at 11:19:47AM -0500, Milton Miller wrote:
> On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
> > On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
> >> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
> >>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
> > [snip]
> >>>> +#define MIN_VERSION 2
> >>>> +#define OUT_VERSION 16
> >>>
> >>> Should output version 17. In any case, don't try to be so general -
> >>> just convert v123 (all basically the same) to latest (i.e. v17)
> >>> without all the #if nonsense.
> >>
> >> Outputing v17 instead of 16 requires more words to be added to the
> >> header, and the library does fine with v16.
> >
> > For now. libfdt will want v17. Although it will (eventually) have
> > it's own v16->v17 conversion code.
>
> If libfdt gets merged without supporting v16 input, then that will be a
> regression. This code isn't pretending to address that. The current
> flat tree code works with v16.
Hrm, true. Since I'm working on merging libfdt right now, I guess
that moves up my schedule for getting the v16->v17 conversion code
working.
>
> >> Actually the v1 trees has
> >> some other differences such as initrd addresses were kernel linear not
> >> real, cpus were assigned logical numbers ... so while the structure
> >> didn't change except for the header field, the contents did.
> >
> > !? what's your source for this. v2 and v3 were absolutely supposed to
> > be backwards compatible with v1 which would not be the case with
> > silent semantic changes such as this.
>
> What's your souce for saying the were supposed to be backwards
> compatable? That dtc fills out the struct header so?
Sitting next to BenH and knowing he always intended them to be so.
> My source is my involvment when v2 was defined (they were discovered
> while writing my device tree generation code):
>
> The actual binary structure is compatable, just not the contents of the
> properties nor how any slave cpus wait (for some trees it doesn't
> matter).
>
> http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
> testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
> hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
An old version of fs2dt is hardly definitive. It could just be Plain
Wrong, nothing to do with the dt version.
> And some more changes just before that:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
> a=history;f=arch/ppc64/kernel/prom_init.c;
> h=e570799a84cc5328e9f0fd44592cb0b828d8c13a;
> hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc
I don't know what bit you're referring to in that batch of commits.
> So its mostly when the kernel generated and required v1 trees, it was
> ppc64 only and had these other content and handoff semantics. If it
> were to get a v1 tree, it only copes for the boot cpu determination
> I'm not aware of any code other than the kernel that would actually
> generate a v1 tree (other than dtc, which always supporteed v2, and
> doesn't care about these differences).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Michael Ellerman @ 2007-09-27 2:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <8FC0C4ED-3268-467C-A3EF-0336082062E1@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 3889 bytes --]
On Wed, 2007-09-26 at 00:37 -0500, Kumar Gala wrote:
> On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
>
> > Kumar Gala wrote:
> >>
> >> On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
> >>
> >>> Kumar Gala wrote:
> >>>>
> >>>> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> >>>>
> >>>>> Update dump_task_altivec() (that has so far never been put to use)
> >>>>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
> >>>>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
> >>>>> the appropriate glue typedefs and #defines to
> >>>>> include/asm-powerpc/elf.h for it to work.
> >>>>
> >>>> Is there some way to tell if the core dump has altivec registers
> >>>> state
> >>>> in it?
> >>>>
> >>>> I'm wondering how we distinguish a core dump w/altivec state vs
> >>>> one with
> >>>> SPE state.
> >>>>
> >>>> - k
> >>>>
> >>>>
> >>>
> >>> If the core dump has the Altivec registers saved in there it will
> >>> have a
> >>> note called LINUX as shown below:
> >>>
> >>> $ readelf -n core
> >>>
> >>> Notes at offset 0x000002b4 with length 0x000005c8:
> >>> Owner Data size Description
> >>> CORE 0x0000010c NT_PRSTATUS (prstatus structure)
> >>> CORE 0x00000080 NT_PRPSINFO (prpsinfo structure)
> >>> CORE 0x000000b0 NT_AUXV (auxiliary vector)
> >>> CORE 0x00000108 NT_FPREGSET (floating point
> >>> registers)
> >>> LINUX 0x00000220 NT_PRXFPREG (user_xfpregs structure)
> >>>
> >>> This mirrors what occurs with the SSE registers on i386 core
> >>> dumps in
> >>> order to keep things as similar as possible.
> >>>
> >>> I can't find any place where dump_spe() is called at the moment,
> >>> but I
> >>> suppose if it were to be hooked up in the future it could cause
> >>> confusion.
> >>> The Altivec register state in the core file is much larger than what
> >>> would be dumped by the current dump_spe(), but I'm not sure if that
> >>> matters...
> >>>
> >>> There's a patch for GDB that currently reads the contents of
> >>> these vector
> >>> registers from the core file, but it's being held until this
> >>> patch has
> >>> been commented on and/or approved of, so if it comes to it the
> >>> note name
> >>> could be changed to ALTIVEC (or something similar).
> >>
> >> I think we should NOT overload NT_PRXFPREG and add proper note types
> >> NT_ALTIVEC & NT_SPE for those register sets.
> >>
> >> Who on the GDB side would we need to coordinate such a change with?
> >>
> >> - k
> >>
> >
> > You're probably right :)
> >
> > What cores have SPE at the moment? Also, perhaps more importantly,
> > are there any plans to have Altivec and SPE in the same core?
>
> The e500 cores's from Freescale.
>
> No, they are pretty much mutually exclusive.
>
> > I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
> > the GDB side of this.
>
> From comments it looks like the expectation is that the combination
> of note type and name which is expected to be unique.
>
> I'm wondering if we should handle this via
> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
> Does GDB care about the order it sees the various sections in?
I don't think those callbacks will work in this case, they're only
called for the primary thread that's doing the coredump, not for each
thread. Perhaps there's a way to adapt it though.
I think the easiest solution for now is just to make the note type a
#define and create a new value for Altivec.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Michael Ellerman @ 2007-09-27 2:53 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Carlos Eduardo Seo
In-Reply-To: <Pine.LNX.4.62.0709260937540.6243@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
On Wed, 2007-09-26 at 09:42 +0200, Geert Uytterhoeven wrote:
> On Wed, 26 Sep 2007, Kumar Gala wrote:
> > On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> > > What cores have SPE at the moment? Also, perhaps more importantly,
> > > are there any plans to have Altivec and SPE in the same core?
> >
> > The e500 cores's from Freescale.
> >
> > No, they are pretty much mutually exclusive.
>
> Bummer, only now do I realize this thread is not about the Synergistic
> Processing Elements but about the Signal Processing Extension...
Yeah, it's a bit of a downer. Luckily most of the Cell kernel code uses
SPU rather than SPE.
Happily it looks like SPU will become ambiguous if Niagara II support
lands in the kernel:
http://realworldtech.com/page.cfm?ArticleID=RWT090406012516&p=2
sigh :)
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS
From: Nethra @ 2007-09-27 4:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070925152301.GC15739@ld0162-tx32.am.freescale.net>
> Header CRC failed on REF_PRISTINE node at 0x0063b24c: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002b4)
> Header CRC failed on REF_PRISTINE node at 0x0063b500: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002c8)
> Header CRC failed on REF_PRISTINE node at 0x0063b7c8: Read 0xffffffff,
> calculated 0x44660075
>
> are they debug messages or warnings...?
>>They are errors.
which are all the most possible reasons for these errors ?
> # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
> # CONFIG_MTD_CFI_I1 is not set
> CONFIG_MTD_CFI_I2=y
> # CONFIG_MTD_CFI_I4 is not set
> # CONFIG_MTD_CFI_I8 is not set
[snip]
> #
> # Mapping drivers for chip access
> #
> # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0xFC000000
> CONFIG_MTD_PHYSMAP_LEN=0x4000000CONFIG_MTD_PHYSMAP_BANKWIDTH=4
> # CONFIG_MTD_MULTI_PHYSMAP is not set
> # CONFIG_MTD_SBC8240 is not set
> CONFIG_MTD_PQ2FADS=y
> # CONFIG_MTD_PLATRAM is not set
>>Are you using a non-standard flash SIMM? The one that comes with the
>>board (that I've seen, at least) have interleave 4, and are mapped at
>>0xfe000000.
First of all this is CUSTOM board similar to MPC8272ADS.
We are using flash which is different from flash that comes with the
MPC8272ADS board.
FLASH: S29GL256N90TF
Total size is 64 MB with 2 flash interleave
mapped at 0xfc000000.
>>Was it the physmap driver or the pq2fads driver that found the flash?
Flash is cfi compatible.
>>Which kernel are you using, and are you using arch/ppc or arch/powerpc?
>> -Scott
KERNEL: linux-2.6.10 and we r using arc/ppc
Nethra
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/jffs2-file-system-on-MPC8272ADS-tf4513571.html#a12914822
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Ishizaki Kou @ 2007-09-27 7:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This is a patch kit to work with new Guest OS Interface
to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
automatically.
Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
---
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/setup.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/setup.c
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/setup.c
@@ -119,7 +119,7 @@ static int __init celleb_probe(void)
return 0;
powerpc_firmware_features |= FW_FEATURE_CELLEB_POSSIBLE;
- hpte_init_beat();
+ hpte_init_beat_v3();
return 1;
}
Index: linux-powerpc-git/include/asm-powerpc/mmu-hash64.h
===================================================================
--- linux-powerpc-git.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-powerpc-git/include/asm-powerpc/mmu-hash64.h
@@ -256,6 +256,7 @@ extern void hpte_init_native(void);
extern void hpte_init_lpar(void);
extern void hpte_init_iSeries(void);
extern void hpte_init_beat(void);
+extern void hpte_init_beat_v3(void);
extern void stabs_alloc(void);
extern void slb_initialize(void);
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/beat_syscall.h
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/beat_syscall.h
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/beat_syscall.h
@@ -157,4 +157,8 @@
#define HV_rtc_write __BEAT_ADD_VENDOR_ID(0x191, 1)
#define HV_eeprom_read __BEAT_ADD_VENDOR_ID(0x192, 1)
#define HV_eeprom_write __BEAT_ADD_VENDOR_ID(0x193, 1)
+#define HV_insert_htab_entry3 __BEAT_ADD_VENDOR_ID(0x104, 1)
+#define HV_invalidate_htab_entry3 __BEAT_ADD_VENDOR_ID(0x105, 1)
+#define HV_update_htab_permission3 __BEAT_ADD_VENDOR_ID(0x106, 1)
+#define HV_clear_htab3 __BEAT_ADD_VENDOR_ID(0x107, 1)
#endif
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/beat_wrapper.h
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/beat_wrapper.h
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/beat_wrapper.h
@@ -98,6 +98,37 @@ static inline s64 beat_write_htab_entry(
return ret;
}
+static inline s64 beat_insert_htab_entry3(u64 htab_id, u64 group,
+ u64 hpte_v, u64 hpte_r, u64 mask_v, u64 value_v, u64 *slot)
+{
+ u64 dummy[1];
+ s64 ret;
+
+ ret = beat_hcall1(HV_insert_htab_entry3, dummy, htab_id, group,
+ hpte_v, hpte_r, mask_v, value_v);
+ *slot = dummy[0];
+ return ret;
+}
+
+static inline s64 beat_invalidate_htab_entry3(u64 htab_id, u64 group,
+ u64 va, u64 pss)
+{
+ return beat_hcall_norets(HV_invalidate_htab_entry3,
+ htab_id, group, va, pss);
+}
+
+static inline s64 beat_update_htab_permission3(u64 htab_id, u64 group,
+ u64 va, u64 pss, u64 ptel_mask, u64 ptel_value)
+{
+ return beat_hcall_norets(HV_update_htab_permission3,
+ htab_id, group, va, pss, ptel_mask, ptel_value);
+}
+
+static inline s64 beat_clear_htab3(u64 htab_id)
+{
+ return beat_hcall_norets(HV_clear_htab3, htab_id);
+}
+
static inline void beat_shutdown_logical_partition(u64 code)
{
(void)beat_hcall_norets(HV_shutdown_logical_partition, code);
@@ -217,4 +248,41 @@ static inline s64 beat_put_iopte(u64 ioa
ioid, flags);
}
+static inline s64 beat_construct_event_receive_port(u64 *port)
+{
+ u64 dummy[1];
+ s64 ret;
+
+ ret = beat_hcall1(HV_construct_event_receive_port, dummy);
+ *port = dummy[0];
+ return ret;
+}
+
+static inline s64 beat_destruct_event_receive_port(u64 port)
+{
+ s64 ret;
+
+ ret = beat_hcall_norets(HV_destruct_event_receive_port, port);
+ return ret;
+}
+
+static inline s64 beat_create_repository_node(u64 path[4], u64 data[2])
+{
+ s64 ret;
+
+ ret = beat_hcall_norets(HV_create_repository_node2,
+ path[0], path[1], path[2], path[3], data[0], data[1]);
+ return ret;
+}
+
+static inline s64 beat_get_repository_node_value(u64 lpid, u64 path[4],
+ u64 data[2])
+{
+ s64 ret;
+
+ ret = beat_hcall2(HV_get_repository_node_value2, data,
+ lpid, path[0], path[1], path[2], path[3]);
+ return ret;
+}
+
#endif
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/htab.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/htab.c
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/htab.c
@@ -306,3 +306,133 @@ void __init hpte_init_beat(void)
ppc_md.hpte_remove = beat_lpar_hpte_remove;
ppc_md.hpte_clear_all = beat_lpar_hptab_clear;
}
+
+static long beat_lpar_hpte_insert_v3(unsigned long hpte_group,
+ unsigned long va, unsigned long pa,
+ unsigned long rflags, unsigned long vflags,
+ int psize)
+{
+ unsigned long lpar_rc;
+ unsigned long slot;
+ unsigned long hpte_v, hpte_r;
+
+ /* same as iseries */
+ if (vflags & HPTE_V_SECONDARY)
+ return -1;
+
+ if (!(vflags & HPTE_V_BOLTED))
+ DBG_LOW("hpte_insert(group=%lx, va=%016lx, pa=%016lx, "
+ "rflags=%lx, vflags=%lx, psize=%d)\n",
+ hpte_group, va, pa, rflags, vflags, psize);
+
+ hpte_v = hpte_encode_v(va, psize) | vflags | HPTE_V_VALID;
+ hpte_r = hpte_encode_r(pa, psize) | rflags;
+
+ if (!(vflags & HPTE_V_BOLTED))
+ DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
+
+ if (rflags & (_PAGE_GUARDED|_PAGE_NO_CACHE))
+ hpte_r &= ~_PAGE_COHERENT;
+
+ /* insert into not-volted entry */
+ lpar_rc = beat_insert_htab_entry3(0, hpte_group, hpte_v, hpte_r,
+ HPTE_V_BOLTED, 0, &slot);
+ /*
+ * Since we try and ioremap PHBs we don't own, the pte insert
+ * will fail. However we must catch the failure in hash_page
+ * or we will loop forever, so return -2 in this case.
+ */
+ if (unlikely(lpar_rc != 0)) {
+ if (!(vflags & HPTE_V_BOLTED))
+ DBG_LOW(" lpar err %lx\n", lpar_rc);
+ return -2;
+ }
+ if (!(vflags & HPTE_V_BOLTED))
+ DBG_LOW(" -> slot: %lx\n", slot);
+
+ /* We have to pass down the secondary bucket bit here as well */
+ return (slot ^ hpte_group) & 15;
+}
+
+/*
+ * NOTE: for updatepp ops we are fortunate that the linux "newpp" bits and
+ * the low 3 bits of flags happen to line up. So no transform is needed.
+ * We can probably optimize here and assume the high bits of newpp are
+ * already zero. For now I am paranoid.
+ */
+static long beat_lpar_hpte_updatepp_v3(unsigned long slot,
+ unsigned long newpp,
+ unsigned long va,
+ int psize, int local)
+{
+ unsigned long lpar_rc;
+ unsigned long want_v;
+ unsigned long pss;
+
+ want_v = hpte_encode_v(va, psize);
+ pss = (psize == MMU_PAGE_4K) ? -1UL : mmu_psize_defs[psize].penc;
+
+ DBG_LOW(" update: "
+ "avpnv=%016lx, slot=%016lx, psize: %d, newpp %016lx ... ",
+ want_v & HPTE_V_AVPN, slot, psize, newpp);
+
+ lpar_rc = beat_update_htab_permission3(0, slot, want_v, pss, 7, newpp);
+
+ if (lpar_rc == 0xfffffff7) {
+ DBG_LOW("not found !\n");
+ return -1;
+ }
+
+ DBG_LOW("ok\n");
+
+ BUG_ON(lpar_rc != 0);
+
+ return 0;
+}
+
+static void beat_lpar_hpte_invalidate_v3(unsigned long slot, unsigned long va,
+ int psize, int local)
+{
+ unsigned long want_v;
+ unsigned long lpar_rc;
+ unsigned long pss;
+
+ DBG_LOW(" inval : slot=%lx, va=%016lx, psize: %d, local: %d\n",
+ slot, va, psize, local);
+ want_v = hpte_encode_v(va, psize);
+ pss = (psize == MMU_PAGE_4K) ? -1UL : mmu_psize_defs[psize].penc;
+
+ lpar_rc = beat_invalidate_htab_entry3(0, slot, want_v, pss);
+
+ /* E_busy can be valid output: page may be already replaced */
+ BUG_ON(lpar_rc != 0 && lpar_rc != 0xfffffff7);
+}
+
+static int64_t _beat_lpar_hptab_clear_v3(void)
+{
+ return beat_clear_htab3(0);
+}
+
+static void beat_lpar_hptab_clear_v3(void)
+{
+ _beat_lpar_hptab_clear_v3();
+}
+
+void __init hpte_init_beat_v3(void)
+{
+ if (_beat_lpar_hptab_clear_v3() == 0) {
+ ppc_md.hpte_invalidate = beat_lpar_hpte_invalidate_v3;
+ ppc_md.hpte_updatepp = beat_lpar_hpte_updatepp_v3;
+ ppc_md.hpte_updateboltedpp = beat_lpar_hpte_updateboltedpp;
+ ppc_md.hpte_insert = beat_lpar_hpte_insert_v3;
+ ppc_md.hpte_remove = beat_lpar_hpte_remove;
+ ppc_md.hpte_clear_all = beat_lpar_hptab_clear_v3;
+ } else {
+ ppc_md.hpte_invalidate = beat_lpar_hpte_invalidate;
+ ppc_md.hpte_updatepp = beat_lpar_hpte_updatepp;
+ ppc_md.hpte_updateboltedpp = beat_lpar_hpte_updateboltedpp;
+ ppc_md.hpte_insert = beat_lpar_hpte_insert;
+ ppc_md.hpte_remove = beat_lpar_hpte_remove;
+ ppc_md.hpte_clear_all = beat_lpar_hptab_clear;
+ }
+}
^ permalink raw reply
* [PATCH 5/7] Celleb: Supports VFD on Celleb 2
From: Ishizaki Kou @ 2007-09-27 7:56 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This is a patch to support VFD on Celleb 2.
VFD is a small LCD to show miscellaneous messages.
Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
---
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/Kconfig
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/Kconfig
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/Kconfig
@@ -7,3 +7,9 @@ config PPC_CELLEB
select PPC_UDBG_BEAT
select USB_OHCI_BIG_ENDIAN_MMIO
select USB_EHCI_BIG_ENDIAN_MMIO
+ select PPC_RTAS
+
+config PPC_CELLEB2_INDICATOR
+ tristate "Support for Toshiba's Cell Reference Set 'Celleb 2's VFD"
+ default m
+ depends on PPC_CELLEB
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/Makefile
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/Makefile
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PPC_UDBG_BEAT) += udbg_beat.o
obj-$(CONFIG_SERIAL_TXX9) += scc_sio.o
obj-$(CONFIG_SPU_BASE) += spu_priv1.o
+obj-$(CONFIG_PPC_CELLEB2_INDICATOR) += indicator.o
Index: linux-powerpc-git/arch/powerpc/platforms/celleb/indicator.c
===================================================================
--- /dev/null
+++ linux-powerpc-git/arch/powerpc/platforms/celleb/indicator.c
@@ -0,0 +1,202 @@
+/*
+ * LED/VFD support for Celleb
+ *
+ * (C) Copyright 2007 TOSHIBA CORPORATION
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/seq_file.h>
+#include <linux/proc_fs.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/uaccess.h>
+
+#include <asm/rtas.h>
+#include <asm/machdep.h>
+#include <asm/semaphore.h>
+
+static const u32 *display_cols;
+static u32 display_width, display_lines;
+static u32 token_display_character, token_set_indicator;
+static DECLARE_MUTEX(display_lock);
+static DECLARE_MUTEX(indicator_lock);
+
+static int celleb_display_show(struct seq_file *m, void *v)
+{
+ u32 i;
+
+ seq_printf(m, "--- Celleb Subdisplay ---\n");
+ seq_printf(m, "Lines: %u\n", display_lines);
+ if (display_cols)
+ for (i = 0; i < display_lines; i++)
+ seq_printf(m, "Columns(%u): %u\n", i, display_cols[i]);
+ else
+ seq_printf(m, "Columns(All): %u\n", display_width);
+ return 0;
+}
+
+static ssize_t celleb_display_write(struct file *file,
+ const char __user *buf, size_t count, loff_t *ppos)
+{
+ int rc;
+ size_t i;
+ char d;
+
+ rc = down_interruptible(&indicator_lock);
+ if (rc != 0)
+ return rc;
+ for (i = 0; i < count; i++) {
+ rc = get_user(d, &buf[i]);
+ if (rc != 0) {
+ up(&display_lock);
+ return rc;
+ }
+ do {
+ rc = rtas_call(token_display_character, 1, 1, NULL, d);
+ } while (rtas_busy_delay(rc));
+ }
+ up(&display_lock);
+ return i;
+}
+
+static int celleb_display_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, celleb_display_show, NULL);
+}
+
+static int celleb_indicator_show(struct seq_file *m, void *v)
+{
+ return 0;
+}
+
+static ssize_t celleb_indicator_write(struct file *file,
+ const char __user *buf, size_t count, loff_t *ppos)
+{
+ int rc;
+ size_t i;
+ char d;
+
+ rc = down_interruptible(&indicator_lock);
+ if (rc != 0)
+ return rc;
+ for (i = 0; i < count; i++) {
+ rc = get_user(d, &buf[i]);
+ if (rc != 0) {
+ up(&indicator_lock);
+ return rc;
+ }
+ do {
+ rc = rtas_call(token_set_indicator, 1, 1, NULL, d);
+ } while (rtas_busy_delay(rc));
+ }
+ up(&indicator_lock);
+ return i;
+}
+
+static int celleb_indicator_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, celleb_indicator_show, NULL);
+}
+
+const struct file_operations celleb_display_operations = {
+ .open = celleb_display_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .write = celleb_display_write,
+ .release = single_release,
+};
+
+const struct file_operations celleb_indicator_operations = {
+ .open = celleb_indicator_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .write = celleb_indicator_write,
+ .release = single_release,
+};
+
+static int __init celleb_indicator_init(void)
+{
+ struct device_node *rtas_node = NULL;
+ struct proc_dir_entry *entry;
+ const u32 *p;
+
+ if (!machine_is(celleb))
+ return -ENODEV;
+
+ rtas_node = of_find_node_by_name(NULL, "rtas");
+ if (rtas_node == NULL)
+ return -ENODEV;
+
+ display_cols = of_get_property(rtas_node,
+ "ibm,display-truncation-length", NULL);
+ if ((p = of_get_property(rtas_node,
+ "ibm,display-line-length", NULL)) != NULL)
+ display_width = *p;
+ else
+ display_width = 0;
+ if ((p = of_get_property(rtas_node,
+ "ibm,display-number-of-lines", NULL)) != NULL)
+ display_lines = *p;
+ else
+ display_lines = 0;
+
+ if ((p = of_get_property(rtas_node,
+ "display-character", NULL)) != NULL)
+ token_display_character = *p;
+ else
+ token_display_character = 0;
+
+ if ((p = of_get_property(rtas_node,
+ "set-indicator", NULL)) != NULL)
+ token_set_indicator = *p;
+ else
+ token_set_indicator = 0;
+
+ if (token_display_character != 0
+ && display_lines != 0
+ && (display_width != 0 || display_cols)) {
+ entry = create_proc_entry("ppc64/rtas/toshiba,display",
+ S_IRUGO|S_IWUSR, NULL);
+ if (entry)
+ entry->proc_fops = &celleb_display_operations;
+ }
+
+ if (token_set_indicator != 0) {
+ entry = create_proc_entry("ppc64/rtas/toshiba,indicator",
+ S_IRUGO|S_IWUSR, NULL);
+ if (entry)
+ entry->proc_fops = &celleb_indicator_operations;
+ }
+ of_node_put(rtas_node);
+
+ return 0;
+}
+
+static void __exit celleb_indicator_exit(void)
+{
+ remove_proc_entry("ppc64/rtas/toshiba,display", NULL);
+ remove_proc_entry("ppc64/rtas/toshiba,indicator", NULL);
+}
+
+module_init(celleb_indicator_init);
+module_exit(celleb_indicator_exit);
+MODULE_AUTHOR("Toshiba Corporation");
+MODULE_DESCRIPTION("VFD/LED support for Toshiba Cell Reference Set");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("1.0");
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: kou.ishizaki @ 2007-09-27 8:01 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
initializing SLB
In-Reply-To: <200709261415.35404.arnd@arndb.de>
From: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> On Wednesday 26 September 2007, Ishizaki Kou wrote:
> > This is a workaround NOT to insert EA=0 entry at initializing SLB.
> > Without this patch, you can see /sbin/init hanging at a machine
> > which has less or equal than 256MB memory.
> Can you elaborate? I don't understand why /sbin/init will hang
> because of an incorrect SLB entry, or how that entry gets
> initialized from get_paca()->kstack.
For latter question, following scenario will occur:
mm/slb.c:slb_flush_and_rebolt() function rebolts SLB entry 1 and 2
by VMALLOC segment and kernel stack segment respectively, but
if we have get_paca()->kstack is set to zero, following condition
will be false,
------------------------------------------------------------------------
105: if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET) {
------------------------------------------------------------------------
so following line will create shadowed bolted SLB entry 2 with EA=0
------------------------------------------------------------------------
111: slb_shadow_update(get_paca()->kstack, lflags, 2);
------------------------------------------------------------------------
and following lines will create real bolted SLB entry 2.
------------------------------------------------------------------------
125: "r"(mk_vsid_data(ksp_esid_data, lflags),
126: "r"(ksp_esid_data)
------------------------------------------------------------------------
Celleb does not set get_paca()->kstack properly (I don't know which
function should set it up), so we need to workaround.
If we have more than 256MB, SLB entry 2 will be overridden with second
segment of the main storage, so the problem will be washed out.
For former question, bolted SLB entries should not be erased even
if /sbin/init is exec()'ed. Our /sbin/init starts at 0x01000000,
at Segment=0. So SLB entry 2 matches. And the processor fetches
instructions from the kernel, not /sbin/init.
Do above expressions make sense?
> Are you still trying to find a better fix for 2.6.24, or do
> you intend to have this patch go in for now?
I believe setting get_paca()->kstack properly will solve this problem.
Do you have any idea?
> Also, I did not get a patch 4/7 and 5/7. Did you send them to
> some other mailing list, or did they get lost on the way?
I don't have them too. It seems that they are lost. I resent them.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-27 8:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
Hi all
I am using "test_bit(),set_bit(),clear_bit() etc" API functions provided by
the Linux kernel. I want to know that if anybody is used it and have full
faith in its operation then please let me know. Driver in the while loop is
calling these API's hence i want to make sure that its operation will remain
stable.
I need your comments in this regard
Thank you
Misbah
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12916782
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
[-- Attachment #2: Type: text/html, Size: 912 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-27 8:18 UTC (permalink / raw)
To: kou.ishizaki; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070927.170139.-1300534448.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 17:01 +0900, kou.ishizaki@toshiba.co.jp wrote:
>
> Celleb does not set get_paca()->kstack properly (I don't know which
> function should set it up), so we need to workaround.
paca->kstack is set in asm (via the PACAKSAVE macro), from either
__secondary_start for non-boot CPUs or from start_here_common for the
boot CPU.
slb_flush_and_rebolt() should not be called before that happens.
How do you end up with kstack set to 0 ?
Ben.
^ permalink raw reply
* Re: [PATCH 7/7] Celleb: update for PCI
From: Benjamin Herrenschmidt @ 2007-09-27 8:25 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200709261409.32231.arnd@arndb.de>
On Wed, 2007-09-26 at 14:09 +0200, Arnd Bergmann wrote:
> Is there a way that we can make that code common? I guess there could be a
> file in arch/powerpc/sysdev that can handle this correctly for all hardware
> that requires this particular workaround (currently celleb and QS20, but
> potentially more).
We could move it to something like sysdev/spider-pci-workarounds.c
Another thing to note is that the initial implementation I did for QS20
only does PCI, not PCIE. Maybe that's worth fixing on both.
Ben.
^ permalink raw reply
* Re: [PATCH 2/7] Celleb: Move pause, kexec_cpu_down to beat.c
From: Ishizaki Kou @ 2007-09-27 8:27 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <200709261340.51450.arnd@arndb.de>
> On Wednesday 26 September 2007, Ishizaki Kou wrote:
> > This patch is an update for "Beat on Celleb"
> > - Move beat_pause(), beat_kexec_cpu_down() from setup.c to beat.c
> >=20
> > Signed-off-by: <Kou.Ishizaki@toshiba.co.jp>
>=20
> Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>=20
> The patch looks good, once you fix this one line:
>=20
> > @@ -36,5 +36,9 @@ ssize_t beat_nvram_get_size(void);
> > ssize_t beat_nvram_read(char *, size_t, loff_t *);
> > ssize_t beat_nvram_write(char *, size_t, loff_t *);
> > int beat_set_xdabr(unsigned long);
> > +void beat_power_save(void);
> > +#ifdef CONFIG_KEXEC
> > +void beat_kexec_cpu_down(int, int);
> > +#endif
>=20
> Function declarations in headers files should not be enclosed in =
#ifdef,
> it only causes unnecessary rebuilds when the configuration changes, =
but
> does not help.
Agreed. I'll post an updated patch.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Benjamin Herrenschmidt @ 2007-09-27 8:31 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927.165326.-1300536104.kouish@swc.toshiba.co.jp>
On Thu, 2007-09-27 at 16:53 +0900, Ishizaki Kou wrote:
> This is a patch kit to work with new Guest OS Interface
> to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
> automatically.
You may also consider adding an API to Beat to invalidate ranges of
addresses. We could us that through the batch invalidate mechanism to
speed up significantly process tear down and forks typically.
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
> ---
>
> Index: linux-powerpc-git/arch/powerpc/platforms/celleb/setup.c
> ===================================================================
> --- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/setup.c
> +++ linux-powerpc-git/arch/powerpc/platforms/celleb/setup.c
> @@ -119,7 +119,7 @@ static int __init celleb_probe(void)
> return 0;
>
> powerpc_firmware_features |= FW_FEATURE_CELLEB_POSSIBLE;
> - hpte_init_beat();
> + hpte_init_beat_v3();
> return 1;
> }
>
> Index: linux-powerpc-git/include/asm-powerpc/mmu-hash64.h
> ===================================================================
> --- linux-powerpc-git.orig/include/asm-powerpc/mmu-hash64.h
> +++ linux-powerpc-git/include/asm-powerpc/mmu-hash64.h
> @@ -256,6 +256,7 @@ extern void hpte_init_native(void);
> extern void hpte_init_lpar(void);
> extern void hpte_init_iSeries(void);
> extern void hpte_init_beat(void);
> +extern void hpte_init_beat_v3(void);
>
> extern void stabs_alloc(void);
> extern void slb_initialize(void);
> Index: linux-powerpc-git/arch/powerpc/platforms/celleb/beat_syscall.h
> ===================================================================
> --- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/beat_syscall.h
> +++ linux-powerpc-git/arch/powerpc/platforms/celleb/beat_syscall.h
> @@ -157,4 +157,8 @@
> #define HV_rtc_write __BEAT_ADD_VENDOR_ID(0x191, 1)
> #define HV_eeprom_read __BEAT_ADD_VENDOR_ID(0x192, 1)
> #define HV_eeprom_write __BEAT_ADD_VENDOR_ID(0x193, 1)
> +#define HV_insert_htab_entry3 __BEAT_ADD_VENDOR_ID(0x104, 1)
> +#define HV_invalidate_htab_entry3 __BEAT_ADD_VENDOR_ID(0x105, 1)
> +#define HV_update_htab_permission3 __BEAT_ADD_VENDOR_ID(0x106, 1)
> +#define HV_clear_htab3 __BEAT_ADD_VENDOR_ID(0x107, 1)
> #endif
> Index: linux-powerpc-git/arch/powerpc/platforms/celleb/beat_wrapper.h
> ===================================================================
> --- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/beat_wrapper.h
> +++ linux-powerpc-git/arch/powerpc/platforms/celleb/beat_wrapper.h
> @@ -98,6 +98,37 @@ static inline s64 beat_write_htab_entry(
> return ret;
> }
>
> +static inline s64 beat_insert_htab_entry3(u64 htab_id, u64 group,
> + u64 hpte_v, u64 hpte_r, u64 mask_v, u64 value_v, u64 *slot)
> +{
> + u64 dummy[1];
> + s64 ret;
> +
> + ret = beat_hcall1(HV_insert_htab_entry3, dummy, htab_id, group,
> + hpte_v, hpte_r, mask_v, value_v);
> + *slot = dummy[0];
> + return ret;
> +}
> +
> +static inline s64 beat_invalidate_htab_entry3(u64 htab_id, u64 group,
> + u64 va, u64 pss)
> +{
> + return beat_hcall_norets(HV_invalidate_htab_entry3,
> + htab_id, group, va, pss);
> +}
> +
> +static inline s64 beat_update_htab_permission3(u64 htab_id, u64 group,
> + u64 va, u64 pss, u64 ptel_mask, u64 ptel_value)
> +{
> + return beat_hcall_norets(HV_update_htab_permission3,
> + htab_id, group, va, pss, ptel_mask, ptel_value);
> +}
> +
> +static inline s64 beat_clear_htab3(u64 htab_id)
> +{
> + return beat_hcall_norets(HV_clear_htab3, htab_id);
> +}
> +
> static inline void beat_shutdown_logical_partition(u64 code)
> {
> (void)beat_hcall_norets(HV_shutdown_logical_partition, code);
> @@ -217,4 +248,41 @@ static inline s64 beat_put_iopte(u64 ioa
> ioid, flags);
> }
>
> +static inline s64 beat_construct_event_receive_port(u64 *port)
> +{
> + u64 dummy[1];
> + s64 ret;
> +
> + ret = beat_hcall1(HV_construct_event_receive_port, dummy);
> + *port = dummy[0];
> + return ret;
> +}
> +
> +static inline s64 beat_destruct_event_receive_port(u64 port)
> +{
> + s64 ret;
> +
> + ret = beat_hcall_norets(HV_destruct_event_receive_port, port);
> + return ret;
> +}
> +
> +static inline s64 beat_create_repository_node(u64 path[4], u64 data[2])
> +{
> + s64 ret;
> +
> + ret = beat_hcall_norets(HV_create_repository_node2,
> + path[0], path[1], path[2], path[3], data[0], data[1]);
> + return ret;
> +}
> +
> +static inline s64 beat_get_repository_node_value(u64 lpid, u64 path[4],
> + u64 data[2])
> +{
> + s64 ret;
> +
> + ret = beat_hcall2(HV_get_repository_node_value2, data,
> + lpid, path[0], path[1], path[2], path[3]);
> + return ret;
> +}
> +
> #endif
> Index: linux-powerpc-git/arch/powerpc/platforms/celleb/htab.c
> ===================================================================
> --- linux-powerpc-git.orig/arch/powerpc/platforms/celleb/htab.c
> +++ linux-powerpc-git/arch/powerpc/platforms/celleb/htab.c
> @@ -306,3 +306,133 @@ void __init hpte_init_beat(void)
> ppc_md.hpte_remove = beat_lpar_hpte_remove;
> ppc_md.hpte_clear_all = beat_lpar_hptab_clear;
> }
> +
> +static long beat_lpar_hpte_insert_v3(unsigned long hpte_group,
> + unsigned long va, unsigned long pa,
> + unsigned long rflags, unsigned long vflags,
> + int psize)
> +{
> + unsigned long lpar_rc;
> + unsigned long slot;
> + unsigned long hpte_v, hpte_r;
> +
> + /* same as iseries */
> + if (vflags & HPTE_V_SECONDARY)
> + return -1;
> +
> + if (!(vflags & HPTE_V_BOLTED))
> + DBG_LOW("hpte_insert(group=%lx, va=%016lx, pa=%016lx, "
> + "rflags=%lx, vflags=%lx, psize=%d)\n",
> + hpte_group, va, pa, rflags, vflags, psize);
> +
> + hpte_v = hpte_encode_v(va, psize) | vflags | HPTE_V_VALID;
> + hpte_r = hpte_encode_r(pa, psize) | rflags;
> +
> + if (!(vflags & HPTE_V_BOLTED))
> + DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
> +
> + if (rflags & (_PAGE_GUARDED|_PAGE_NO_CACHE))
> + hpte_r &= ~_PAGE_COHERENT;
> +
> + /* insert into not-volted entry */
> + lpar_rc = beat_insert_htab_entry3(0, hpte_group, hpte_v, hpte_r,
> + HPTE_V_BOLTED, 0, &slot);
> + /*
> + * Since we try and ioremap PHBs we don't own, the pte insert
> + * will fail. However we must catch the failure in hash_page
> + * or we will loop forever, so return -2 in this case.
> + */
> + if (unlikely(lpar_rc != 0)) {
> + if (!(vflags & HPTE_V_BOLTED))
> + DBG_LOW(" lpar err %lx\n", lpar_rc);
> + return -2;
> + }
> + if (!(vflags & HPTE_V_BOLTED))
> + DBG_LOW(" -> slot: %lx\n", slot);
> +
> + /* We have to pass down the secondary bucket bit here as well */
> + return (slot ^ hpte_group) & 15;
> +}
> +
> +/*
> + * NOTE: for updatepp ops we are fortunate that the linux "newpp" bits and
> + * the low 3 bits of flags happen to line up. So no transform is needed.
> + * We can probably optimize here and assume the high bits of newpp are
> + * already zero. For now I am paranoid.
> + */
> +static long beat_lpar_hpte_updatepp_v3(unsigned long slot,
> + unsigned long newpp,
> + unsigned long va,
> + int psize, int local)
> +{
> + unsigned long lpar_rc;
> + unsigned long want_v;
> + unsigned long pss;
> +
> + want_v = hpte_encode_v(va, psize);
> + pss = (psize == MMU_PAGE_4K) ? -1UL : mmu_psize_defs[psize].penc;
> +
> + DBG_LOW(" update: "
> + "avpnv=%016lx, slot=%016lx, psize: %d, newpp %016lx ... ",
> + want_v & HPTE_V_AVPN, slot, psize, newpp);
> +
> + lpar_rc = beat_update_htab_permission3(0, slot, want_v, pss, 7, newpp);
> +
> + if (lpar_rc == 0xfffffff7) {
> + DBG_LOW("not found !\n");
> + return -1;
> + }
> +
> + DBG_LOW("ok\n");
> +
> + BUG_ON(lpar_rc != 0);
> +
> + return 0;
> +}
> +
> +static void beat_lpar_hpte_invalidate_v3(unsigned long slot, unsigned long va,
> + int psize, int local)
> +{
> + unsigned long want_v;
> + unsigned long lpar_rc;
> + unsigned long pss;
> +
> + DBG_LOW(" inval : slot=%lx, va=%016lx, psize: %d, local: %d\n",
> + slot, va, psize, local);
> + want_v = hpte_encode_v(va, psize);
> + pss = (psize == MMU_PAGE_4K) ? -1UL : mmu_psize_defs[psize].penc;
> +
> + lpar_rc = beat_invalidate_htab_entry3(0, slot, want_v, pss);
> +
> + /* E_busy can be valid output: page may be already replaced */
> + BUG_ON(lpar_rc != 0 && lpar_rc != 0xfffffff7);
> +}
> +
> +static int64_t _beat_lpar_hptab_clear_v3(void)
> +{
> + return beat_clear_htab3(0);
> +}
> +
> +static void beat_lpar_hptab_clear_v3(void)
> +{
> + _beat_lpar_hptab_clear_v3();
> +}
> +
> +void __init hpte_init_beat_v3(void)
> +{
> + if (_beat_lpar_hptab_clear_v3() == 0) {
> + ppc_md.hpte_invalidate = beat_lpar_hpte_invalidate_v3;
> + ppc_md.hpte_updatepp = beat_lpar_hpte_updatepp_v3;
> + ppc_md.hpte_updateboltedpp = beat_lpar_hpte_updateboltedpp;
> + ppc_md.hpte_insert = beat_lpar_hpte_insert_v3;
> + ppc_md.hpte_remove = beat_lpar_hpte_remove;
> + ppc_md.hpte_clear_all = beat_lpar_hptab_clear_v3;
> + } else {
> + ppc_md.hpte_invalidate = beat_lpar_hpte_invalidate;
> + ppc_md.hpte_updatepp = beat_lpar_hpte_updatepp;
> + ppc_md.hpte_updateboltedpp = beat_lpar_hpte_updateboltedpp;
> + ppc_md.hpte_insert = beat_lpar_hpte_insert;
> + ppc_md.hpte_remove = beat_lpar_hpte_remove;
> + ppc_md.hpte_clear_all = beat_lpar_hptab_clear;
> + }
> +}
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Xilinx ML403 support in mainline u-boot
From: John Hahn @ 2007-09-27 8:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Hello, I am a newbie about to start sw/hw development on ML403 based
systems.
I apologize if I am repeating a question already addressed in the forum, but
I have gone through past months of the archives without finding the answer.
Based on searching the archived posts
I have downloaded from Xilinx an older version of u-boot (1.1.4)
http://www.xilinx.com/ml410-p/designs/
<http://www.xilinx.com/ml410-p/designs/u-boot.zip> u-boot.zip
which appears to have the ml403 support.
I also cloned the latest u-boot repository from denx (1.3.0-rc2+)
git://www.denx.de/git/u-boot.git
However this tree does not appear to have the ml403 support.
If possible I would prefer to use the latest u-boot tree .
Its there another branch which I need to pull the ml403 support changes?
Thanks
John
[-- Attachment #2: Type: text/html, Size: 3996 bytes --]
^ 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