* Re: rtlinux rtai interrupt latency
From: Wolfgang Denk @ 2007-10-21 21:25 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0710202230230.1476@rtl14.hofr.at>
In message <Pine.LNX.4.60.0710202230230.1476@rtl14.hofr.at> you wrote:
>
> There are free variants around as well - XtratuM/PPC (RTLinux-4.0) is
> running on 440EP/GR and 405 Octobus, im quite sur RTAI also is available
> for AMCC CPUs - check RTAI.org (mailing list link is to be found there)
Not really. RTAI is a dead horse for anything except x86.
Instead, look at Xenomai ==> www.xenomai.org
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
G's Third Law: In spite of all evidence to the contra-
ry, the entire universe is composed of only two basic substances:
magic and bullshit.
H's Dictum: There is no magic ...
^ permalink raw reply
* Re: Device trees and audio codecs
From: Jon Smirl @ 2007-10-21 21:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <a76a128145ec8a8f779727a7e11925ac@kernel.crashing.org>
On 10/21/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > I'm working on ALSA ASoC support for a codec chip on my mpc5200 based
> > target hardware.
>
> What is ASoC?
asoc = ALSA System on a Chip. It is in sound/soc
> > Under ASoC the device drivers for the codec chips are platform
> > independent. In the current ASoC model there are three device
> > drivers: i2s (or spi, etc), the generic codec, and a platform specific
> > 'fabric' driver. Some codecs are linked to both i2c and i2s.
>
> The i2s driver is simply for data transport, the codec driver does,
> well, what codecs do; and what is the fabric driver for? Just to
> know which output ports are which, etc.?
Fabric driver tells how the generic codec is hooked up on the specific
board. Some of the codecs are extremely flexible and can be hooked up
hundreds of different ways. It is like GPIO pins, they are wired in
however is convenient for the design.
> > The fabric driver corresponds to the 'layout-id' in the Apple model.
> > It tells how to configure the generic codec driver for the specific
> > configuration needed by the actual platform hardware.
>
> The apple layout-id selects one of several tables with *lots* of info.
> I think you want a subset of that only.
The fabric/layout-id stuff is platform specific.
> > My target hardware has a codec that is linked to both i2s and i2c. How
> > should it be represented?
>
> Since the codec is addressable on i2c, and not on i2s, it should be
> a child node of the i2c bus it sits on; and then you put a property
> in the codec node pointing to the i2s bus node it is connected to.
> Multiple of those (or multiple entries) if it is connected to more
> than one i2s bus. "i2s-parent" might be a good name for such a prop.
How do we want to be consistent with the Efika which uses an AC97
codec that only connects to i2s?
> > Apple has three entries. One for i2s, one for the codec, and one for
> > soundchip. What is the soundchip entry, does it correspond to real
> > hardware?
> >
> > /proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000:
>
> This is one of the i2s channels on the macio. Dunno why they put
> all those platform-XXX entries in here, (most of) these don't
> logically belong here.
Actually those platform-XXX entries may be the solution I am looking
for. I can use the generic i2s driver to load a fabric driver as an
ALSA module.
> > /proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound:
>
> The codec. I guess Apple puts this here for their weirdo platform-do
> stuff; don't imitate this :-)
>
> > /proc/device-tree/pci@f2000000/mac-io@17/i2c@18000/i2c-bus@0/codec@6a:
>
> The codec. _Do_ put it here in your tree :-)
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Device trees and audio codecs
From: Benjamin Herrenschmidt @ 2007-10-21 22:06 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710211433r7e0cf4b4sf6aed12c57dda375@mail.gmail.com>
On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote:
> > This is one of the i2s channels on the macio. Dunno why they put
> > all those platform-XXX entries in here, (most of) these don't
> > logically belong here.
>
> Actually those platform-XXX entries may be the solution I am looking
> for. I can use the generic i2s driver to load a fabric driver as an
> ALSA module.
Yuck.
Ben.
^ permalink raw reply
* Re: Device trees and audio codecs
From: Jon Smirl @ 2007-10-21 22:12 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <1193004399.6745.39.camel@pasglop>
On 10/21/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote:
> > > This is one of the i2s channels on the macio. Dunno why they put
> > > all those platform-XXX entries in here, (most of) these don't
> > > logically belong here.
> >
> > Actually those platform-XXX entries may be the solution I am looking
> > for. I can use the generic i2s driver to load a fabric driver as an
> > ALSA module.
>
> Yuck.
And your alternative is?
I can use the DTC to load the I2S and codec drivers.
How do I get the platform specific fabric driver loaded? There is no
way to load a driver matching on the platform name.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Device trees and audio codecs
From: Benjamin Herrenschmidt @ 2007-10-21 22:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710211512v238fbc89m35783d5eb5b82bf6@mail.gmail.com>
On Sun, 2007-10-21 at 18:12 -0400, Jon Smirl wrote:
> On 10/21/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > On Sun, 2007-10-21 at 17:33 -0400, Jon Smirl wrote:
> > > > This is one of the i2s channels on the macio. Dunno why they put
> > > > all those platform-XXX entries in here, (most of) these don't
> > > > logically belong here.
> > >
> > > Actually those platform-XXX entries may be the solution I am looking
> > > for. I can use the generic i2s driver to load a fabric driver as an
> > > ALSA module.
> >
> > Yuck.
>
> And your alternative is?
>
> I can use the DTC to load the I2S and codec drivers.
>
> How do I get the platform specific fabric driver loaded? There is no
> way to load a driver matching on the platform name.
platform-do-XXX is unrelated to that. It's a kind of script in a blob
that is used to toggle various bits, it's plain ugly, totally powermac
specific (the code to handle it is in platform/powermac and I won't make
it generic) and so you don't want it... ever.
For your problem, an option is to do like apple, and have a "sound"
pseudo device which represents the "sound subsystem" of the machine
which cn ahave a compatible property and other bits that you can use to
match your fabric against, and loads the other bits & pieces.
Except that I would put it at the root of the tree.
Ben.
^ permalink raw reply
* [PATCH] Uartlite: speed up console output
From: Grant Likely @ 2007-10-21 23:02 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, jacmet
From: Grant Likely <grant.likely@secretlab.ca>
Change the wait_tx routine to call cpu_relax() instead of udelay() to
reduce console output latency and test for the TXFULL bit instead of
TXEMPTY. That way the FIFO doesn't need to by 100% flushed before
writing the next character.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/serial/uartlite.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
index dfef83f..a85f2d3 100644
--- a/drivers/serial/uartlite.c
+++ b/drivers/serial/uartlite.c
@@ -329,12 +329,14 @@ static struct uart_ops ulite_ops = {
static void ulite_console_wait_tx(struct uart_port *port)
{
int i;
+ u8 val;
- /* wait up to 10ms for the character(s) to be sent */
- for (i = 0; i < 10000; i++) {
- if (readb(port->membase + ULITE_STATUS) & ULITE_STATUS_TXEMPTY)
+ /* Spin waiting for TX fifo to have space available */
+ for (i = 0; i < 100000; i++) {
+ val = readb(port->membase + ULITE_STATUS);
+ if ((val & ULITE_STATUS_TXFULL) == 0)
break;
- udelay(1);
+ cpu_relax();
}
}
^ permalink raw reply related
* Re: Device trees and audio codecs
From: Segher Boessenkool @ 2007-10-21 23:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710211433r7e0cf4b4sf6aed12c57dda375@mail.gmail.com>
> Fabric driver tells how the generic codec is hooked up on the specific
> board. Some of the codecs are extremely flexible and can be hooked up
> hundreds of different ways. It is like GPIO pins, they are wired in
> however is convenient for the design.
Gotcha. *Very* much like GPIOs, indeed.
>>> The fabric driver corresponds to the 'layout-id' in the Apple model.
>>> It tells how to configure the generic codec driver for the specific
>>> configuration needed by the actual platform hardware.
>>
>> The apple layout-id selects one of several tables with *lots* of info.
>> I think you want a subset of that only.
>
> The fabric/layout-id stuff is platform specific.
I mean that Apple's layout-id abstraction is "bigger" than your fabric
abstraction seems to be. Not too important a point, anyway.
>>> My target hardware has a codec that is linked to both i2s and i2c.
>>> How
>>> should it be represented?
>>
>> Since the codec is addressable on i2c, and not on i2s, it should be
>> a child node of the i2c bus it sits on; and then you put a property
>> in the codec node pointing to the i2s bus node it is connected to.
>> Multiple of those (or multiple entries) if it is connected to more
>> than one i2s bus. "i2s-parent" might be a good name for such a prop.
>
> How do we want to be consistent with the Efika which uses an AC97
> codec that only connects to i2s?
Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S
device if you do all the interleaving and whatever stuff by hand -- but
then you probably shouldn't call the I2S "host" an I2S anymore, but name
it "ac97" in the device tree, or "this-or-that-i2s-controller-hooked-up-
in-this-particular-crazy-way". You will want to know which driver to
use for the device, and if it's hooked up in "strange and unforeseen"
ways you want to know about it.
Maybe the platform code should do this, dunno.
_Please_ don't name busses that are not plain I2S "i2s" in the device
tree. At best this means you'll need a quirk in the kernel code to deal
with this later.
</rant>
So anyway, why is it inconsistent to have an audio codec that is
configured
over i2c sit on that i2c bus in the device tree as well, and refer to
the i2s
bus it pumps audio data over; vs. having an ac97 codec that sits on an
ac97
bus sit on that ac97 bus in the device tree as well? In both cases, the
device is a child of the bus via which it is addressed.
The one exceptional case would be a dumb codec that isn't addressable
at all;
it would be a device tree child of the dumb transport bus (where else
could
it be put)?
> Actually those platform-XXX entries may be the solution I am looking
> for.
Like Ben already said, no you _do not_ want the platform-do stuff.
Trust
him on this. Or if you're feeling brave, look at the existing kernel
code
that handles some of it ;-P
Segher
^ permalink raw reply
* Re: [PATCH v3] Device tree bindings for Xilinx devices
From: David Gibson @ 2007-10-22 0:29 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Leonid, Arnd Bergmann, microblaze-uclinux, linuxppc-dev,
Wolfgang Reissnegger
In-Reply-To: <20071019234347.38C1111C006B@mail3-dub.bigfish.com>
On Fri, Oct 19, 2007 at 04:42:58PM -0700, Stephen Neuendorffer wrote:
>
> Here's a full .dts generated using an updated version of
> gen_mhs_devtree.py, following the proposal.
> It happens to be a microblaze system, but you get the idea.
>
> Grant: Is this pretty what you intend?
>
> Steve
>
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "ibm,plb4";
> model = "system.mhs";
Although strictly speaking the root node can represent the top-level
system bus, to match the other 4xx chips it would be beter, as Grant
says, to make a /plb node and put the devices under that.
> Ethernet_MAC {
Node names should be lower case, and must include a unit address
derived from the reg property. Furthermore, the generic names
convention means this should be called just "ethernet@...".
> compatible =
> "xilinx,opb-ethernet-1.04.a\0xilinx,opb-ethernet";
> device_type = "opb_ethernet";
> interrupt-parent = <101>;
> interrupts = < 1 0 >;
> reg = < 40c00000 10000 >;
> xilinx,cam-exist = <0>;
> xilinx,dev-blk-id = <0>;
> xilinx,dev-mir-enable = <0>;
> xilinx,dma-present = <1>;
> xilinx,include-dev-pencoder = <0>;
> xilinx,ipif-rdfifo-depth = <4000>;
> xilinx,ipif-wrfifo-depth = <4000>;
> xilinx,jumbo-exist = <0>;
> xilinx,mac-fifo-depth = <10>;
> xilinx,mii-exist = <1>;
> xilinx,opb-clk-period-ps = <2710>;
> xilinx,reset-present = <1>;
> xilinx,rx-dre-type = <0>;
> xilinx,rx-include-csum = <0>;
> xilinx,tx-dre-type = <0>;
> xilinx,tx-include-csum = <0>;
> } ;
> IIC_EEPROM {
Apart from the fact that it should be "eeprom@..." this doesn't look
right. Surely there must be an i2c bridge, then an eeprom device
behind it?
> compatible = "xilinx,opb-iic-1.02.a\0xilinx,opb-iic";
> device_type = "opb_iic";
> interrupt-parent = <101>;
> interrupts = < 2 0 >;
> reg = < 40800000 10000 >;
> xilinx,clk-freq = <5f5e100>;
> xilinx,iic-freq = <186a0>;
> xilinx,ten-bit-adr = <0>;
> } ;
> RS232_Uart_1 {
"serial@...."
> compatible =
> "xilinx,opb-uartlite-1.00.b\0xilinx,opb-uartlite";
> device_type = "opb_uartlite";
device_type = "serial"
> interrupt-parent = <101>;
> interrupts = < 3 0 >;
> reg = < 40600000 10000 >;
> xilinx,baudrate = <2580>;
> xilinx,clk-freq = <5f5e100>;
> xilinx,data-bits = <8>;
> xilinx,odd-parity = <0>;
> xilinx,use-parity = <0>;
> } ;
> chosen {
> bootargs = "root=/dev/xsysace/disc0/part2";
> interrupt-controller = <101>;
> linux,platform = <600>;
> } ;
> cpus {
> #address-cells = <1>;
> #cpus = <1>;
> #size-cells = <0>;
> microblaze_0,6.00. {
Should be "cpu@0".
> 32-bit;
> clock-frequency = <5f5e1000>;
> d-cache-line-size = <10>;
> d-cache-size = <4000>;
> device_type = "cpu";
> i-cache-line-size = <10>;
> i-cache-size = <4000>;
> linux,boot-cpu;
> reg = <0>;
> timebase-frequency = <1fca055>;
> xilinx,cache-byte-size = <4000>;
> xilinx,dcache-baseaddr = <50000000>;
> xilinx,dcache-byte-size = <4000>;
> xilinx,dcache-highaddr = <5fffffff>;
> xilinx,debug-enabled = <1>;
> xilinx,div-zero-exception = <1>;
> xilinx,dopb-bus-exception = <1>;
> xilinx,fpu-exception = <1>;
> xilinx,icache-baseaddr = <50000000>;
> xilinx,icache-highaddr = <5fffffff>;
> xilinx,ill-opcode-exception = <1>;
> xilinx,iopb-bus-exception = <1>;
> xilinx,number-of-pc-brk = <2>;
> xilinx,pvr = <2>;
> xilinx,unaligned-exceptions = <1>;
> xilinx,use-barrel = <1>;
> xilinx,use-dcache = <1>;
> xilinx,use-div = <1>;
> xilinx,use-fpu = <1>;
> xilinx,use-icache = <1>;
> xilinx,use-msr-instr = <1>;
> xilinx,use-pcmp-instr = <1>;
> } ;
> } ;
> debug_module {
> compatible = "xilinx,opb-mdm-2.00.a\0xilinx,opb-mdm";
> device_type = "opb_mdm";
No device_type here.
> reg = < 41400000 10000 >;
> xilinx,mb-dbg-ports = <1>;
> xilinx,uart-width = <8>;
> xilinx,use-uart = <1>;
> } ;
> memory@50000000 {
> device_type = "memory";
> edk_name = "DDR2_SDRAM_32Mx32";
> memreg:reg = < 50000000 10000000 >;
Unless you're actually using the memreg: label, it shouldn't be there.
> } ;
> opb_hwicap_0 {
> compatible =
> "xilinx,opb-hwicap-1.10.a\0xilinx,opb-hwicap";
> device_type = "opb_hwicap";
No device_type.
> reg = < 41300000 10000 >;
> } ;
> opb_intc_0 {
Should be interrupt-controller@...
> #interrupt-cells = <2>;
> compatible = "xilinx,opb-intc-1.00.c\0xilinx,opb-intc";
> device_type = "opb_intc";
No device_type.
> interrupt-controller;
> linux,phandle = <101>;
> reg = < 41200000 10000 >;
> } ;
> opb_timer_1 {
Needs unit address
> compatible =
> "xilinx,opb-timer-1.00.b\0xilinx,opb-timer";
> device_type = "opb_timer";
No device_type here.
> interrupt-parent = <101>;
> interrupts = < 0 0 >;
> reg = < 41c00000 10000 >;
> xilinx,count-width = <20>;
> xilinx,one-timer-only = <1>;
> } ;
> } ;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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: Device trees and audio codecs
From: Jon Smirl @ 2007-10-22 0:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <5cac8057884ac400b0596988414c7ed7@kernel.crashing.org>
On 10/21/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > How do we want to be consistent with the Efika which uses an AC97
> > codec that only connects to i2s?
>
> Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S
> device if you do all the interleaving and whatever stuff by hand -- but
> then you probably shouldn't call the I2S "host" an I2S anymore, but name
> it "ac97" in the device tree, or "this-or-that-i2s-controller-hooked-up-
> in-this-particular-crazy-way". You will want to know which driver to
> use for the device, and if it's hooked up in "strange and unforeseen"
> ways you want to know about it.
I meant an ac97 bus. ac97 is conceptually the same as i2s with the
control signals also routed over it. ac97 and i2s are handled in the
same PSC on the 5200.
I have received conflicting opinions as to whether a codec hooked to
an ac97 bus should get a chip specific codec entry in the device tree.
Without the codec specific entry only generic ac97 features can be
used. The Efika has a STA9766. Looking at the data sheet for the chip
I see that it implements some proprietary functions in addition to the
standard ones.
asoc has a generic ac97 driver. Should the ac97 bus be required to
have a entry for the generic ac97 device? It would make loading the
driver much easier.
> _Please_ don't name busses that are not plain I2S "i2s" in the device
> tree. At best this means you'll need a quirk in the kernel code to deal
> with this later.
the i2s and ac97 drivers for the mpc5200 already exist. I'm using
these preexisting drivers.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: David Gibson @ 2007-10-22 0:36 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, scott.wood
In-Reply-To: <20071020024355.GA20356@lixom.net>
On Fri, Oct 19, 2007 at 09:43:55PM -0500, Olof Johansson wrote:
> Hi,
>
> Did it ever?! I get this with current mainline when building default target:
I think you must have an old dtc; I'm pretty sure I removed the check
for /chosen some time ago. But then I also thought we added a force
to the dtc commant line in wrapper ages ago, so now I'm a bit confused.
> WRAP arch/powerpc/boot/cuImage.8xx
> DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts"
> ERROR: Missing /chosen node
> Input tree has errors
> WRAP arch/powerpc/boot/zImage.ep88xc
> make[1]: *** [arch/powerpc/boot/cuImage.8xx] Error 1
> make[1]: *** Waiting for unfinished jobs....
> DTC: dts->dtb on file "/work/work/linux/k.org/arch/powerpc/boot/dts/ep88xc.dts"
> ERROR: Missing /chosen node
> Input tree has errors
> make[1]: *** [arch/powerpc/boot/zImage.ep88xc] Error 1
> make: *** [zImage] Error 2
>
>
>
> -Olof
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-22 0:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <6a6fcd2bc9b0121cb5e9cfc675d88f57@kernel.crashing.org>
On Sun, Oct 21, 2007 at 07:32:33AM +0200, Segher Boessenkool wrote:
> >> Use of "d#', "o#", "h#" and "b#" are gone in version 1.
> >
> > Also good. We might want to keep b#, since there's no C way of doing
> > binary literals,
>
> GCC supports "0b...", and it is proposed new ISO C syntax, too.
Ah, ok. We should go with that instead, then.
--
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 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-22 0:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20d6133a9294d4f06a7e78ca627ec4f3@kernel.crashing.org>
On Sun, Oct 21, 2007 at 07:30:45AM +0200, Segher Boessenkool wrote:
> > Property names have been limited to start with
> > characters from the set [a-zA-Z,._#?]. That is, the
> > digits and the expression symbols have been removed.
>
> This cannot work; many property names start with a digit,
> for example.
Yes, crap. Ok, I guess we just have to put the literal lexer rule
before the property name lexer rule, so literals will be recognized in
preference. Disallowing just those property names which look like
literals is a little warty, but not likely to cause trouble in
practice, I think.
--
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: ep88xc_defconfig doesn't build
From: Olof Johansson @ 2007-10-22 1:17 UTC (permalink / raw)
To: scott.wood, linuxppc-dev
In-Reply-To: <20071022003625.GC17164@localhost.localdomain>
On Mon, Oct 22, 2007 at 10:36:25AM +1000, David Gibson wrote:
> On Fri, Oct 19, 2007 at 09:43:55PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Did it ever?! I get this with current mainline when building default target:
>
> I think you must have an old dtc; I'm pretty sure I removed the check
> for /chosen some time ago. But then I also thought we added a force
> to the dtc commant line in wrapper ages ago, so now I'm a bit confused.
Hrm, seems like I had an old version. It's a little annoying that it's a
moving target and it's impossible to find out form a built binary which
version it is, besides trying to guess based on file time stamps.
A nice enhancement could be to have a "dtc -v" and have the makefile
verify it before using it.
-Olof
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: Olof Johansson @ 2007-10-22 1:23 UTC (permalink / raw)
To: scott.wood, linuxppc-dev
In-Reply-To: <20071022011740.GA25222@lixom.net>
On Sun, Oct 21, 2007 at 08:17:40PM -0500, Olof Johansson wrote:
> A nice enhancement could be to have a "dtc -v" and have the makefile
> verify it before using it.
Looks like current versions do have "-v", my old one didn't. Apologies.
-Olof
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: David Gibson @ 2007-10-22 1:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, scott.wood
In-Reply-To: <20071022011740.GA25222@lixom.net>
On Sun, Oct 21, 2007 at 08:17:40PM -0500, Olof Johansson wrote:
> On Mon, Oct 22, 2007 at 10:36:25AM +1000, David Gibson wrote:
> > On Fri, Oct 19, 2007 at 09:43:55PM -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Did it ever?! I get this with current mainline when building default target:
> >
> > I think you must have an old dtc; I'm pretty sure I removed the check
> > for /chosen some time ago. But then I also thought we added a force
> > to the dtc commant line in wrapper ages ago, so now I'm a bit confused.
>
> Hrm, seems like I had an old version. It's a little annoying that it's a
> moving target and it's impossible to find out form a built binary which
> version it is, besides trying to guess based on file time stamps.
>
> A nice enhancement could be to have a "dtc -v" and have the makefile
> verify it before using it.
Current dtc has a -v option. Trying to verify it in Makefile (or more
to the point in the wrapper script) would be a bit.. messy (since the
necessary version kind of depends on the dts file anyway).
Avoiding this sort of hassle is why I'd like to put a copy of dtc in
the kernel tree.
--
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 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Ellerman @ 2007-10-22 1:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci
In-Reply-To: <20071021.162131.43417026.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Sun, 2007-10-21 at 16:21 -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Fri, 19 Oct 2007 14:36:56 -0700
>
> > This patch exports the pci_restore_msi_state() function. This function
> > is needed to restore the MSI state during PCI error recovery.
> >
> > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> I'm not so sure about this.
On pseries there's a chance it will work for PCI error recovery, but if
so it's just lucky that firmware has left everything configured the same
way. For actual suspend/resume it will never work, we need to ask
firmware to configure things.
> Perhaps, instead, you should do a pci_msi_disable() and
> pci_msi_enable() in the error detection and recovery sequence.
Yes I think so. That way we can properly reconfigure via the firmware
interface. The other option would be to design some new arch hook to do
resume, but just doing a disable/enable seems simpler to me.
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: SystemACE driver problem
From: John Hahn @ 2007-10-22 2:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710191120w209b62a0l4f71e528e5f1a1b3@mail.gmail.com>
Grant
Regarding your comment about the new xsysace.c driver vs. the old Xilinx
one, is that chosen at the kernel config time ?
i.e.
cp arch/ppc/configs/ml403_defconfig
make ARCH=ppc CROSS_COMPILE=/opt/eldk4.1/usr/bin/ppc_4xx- oldconfig
...
Xilinx SystemACE support (XILINX_SYSACE) [N/m/y/?] (NEW) y
Xilinx SystemACE support (old driver) (XILINX_SYSACE_OLD) [N/m/y/?] (NEW) N
I am also about build and test with the 2.6.23-rc2 same source. Just wanted
to be sure I am choosing the right driver for the ml403 reference design
bits from Xilinx.
Thanks
John Hahn
BCF Semiconductor
---
P.S. Sorry for taking the thread off on a slight tangent ...
> From: Grant Likely
> Sent: Friday, October 19, 2007 11:21 AM
>
... <snip>
>
> I don't know about the old xilinx supplied sysace driver, but the new
> xsysace.c driver is robust enough to work around missed interrupts. I
> don't know of any other problems with the opb_sysace IP core.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: SystemACE driver problem
From: Grant Likely @ 2007-10-22 3:24 UTC (permalink / raw)
To: John Hahn; +Cc: linuxppc-embedded
In-Reply-To: <001a01c81456$985b6a90$c9123fb0$@com>
On 10/21/07, John Hahn <jhahn@bcfsemi.com> wrote:
> Grant
>
> Regarding your comment about the new xsysace.c driver vs. the old Xilinx
> one, is that chosen at the kernel config time ?
>
> i.e.
> cp arch/ppc/configs/ml403_defconfig
> make ARCH=ppc CROSS_COMPILE=/opt/eldk4.1/usr/bin/ppc_4xx- oldconfig
>
> ...
> Xilinx SystemACE support (XILINX_SYSACE) [N/m/y/?] (NEW) y
> Xilinx SystemACE support (old driver) (XILINX_SYSACE_OLD) [N/m/y/?] (NEW) N
>
> I am also about build and test with the 2.6.23-rc2 same source. Just wanted
> to be sure I am choosing the right driver for the ml403 reference design
> bits from Xilinx.
Both drivers work. The new driver is faster, but the old driver is
more featurefull. If one isn't working for you, try the other and
report your experiences with both here to the list.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* ppc manual paging question
From: Wang, Baojun @ 2007-10-22 4:03 UTC (permalink / raw)
To: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, linux-embedded,
Miguel Masmano
hi,
I've got some qeustion about ppc(ppc44x) paging:=20
how can I manually map a virtual address to a physical address through a=20
specific pgd? How does ppc translate virt address to physical one? I think=
=20
besides from tlb, the CPU will search the page table entries via the pgd, c=
an=20
I alter the pgd value to change the memory translation? under i386, it's ve=
ry=20
simple, we can just rewrite %%cr3, it even could invalidate all tlb entries=
=20
automatically, how can I do this under ppc? I've tried rewrite=20
current->mm->pgd and current->thread.pgdir, but sounds like it still not=20
insufficiant, am I missing something vital?=20
Any hint will be greatly approciated.
Regards,
Wang
P.S:
here is the code:
#define save_pd(pd) ((pd) =3D (unsigned long)(current->mm->pgd))
#define load_pd(pd) (current->mm->pgd =3D (pd))
=2E..
static inline pgd_t* __pgd_offset(unsigned long pgd_base, unsigned long va)
{
return (pgd_t*)((pgd_t*)pgd_base + pgd_index(va));
}
static inline pte_t* pte_offset(pmd_t* pte_base, unsigned long va)
{
return (pte_t*)((pte_t*)pte_base + pte_index(va));
}
static inline unsigned long get_free_pages_atomic(int order)
{
return __get_free_pages(GFP_ATOMIC, order);
}
=2E..
unsigned long create_page_directory (unsigned long (*alloc_page) (void)) {
unsigned long pd, c_pd;
unsigned long idx;
save_pd(c_pd);
pd =3D get_free_pages_atomic(PGD_ORDER);
if(!pd) return 0;
memset((void*)pd, 0, PGD_ORDER << PAGE_SHIFT);
/*
* copy kernel page directies
*/
idx =3D pgd_index(PAGE_OFFSET);
memcpy((pgd_t*)pd + idx, (pgd_t*)c_pd + idx, (PTRS_PER_PGD - idx) *=20
sizeof(pgd_t));
printk(KERN_EMERG"create_page_directory return: 0x%lx, c_pd: 0x%lx\n", pd=
,=20
c_pd);
return pd;
}
/*
* allocate a user page at @vaddress if possible
* TODO: add tlb/slb/bat for fast page/block address translation
*/
unsigned long allocate_user_page (unsigned long pd,
unsigned long vaddress,
unsigned long (*alloc_page) (void)) {
pgd_t* pgd;
pud_t* pud;
pmd_t* pmd;
pte_t* pte;
unsigned long page =3D 0;
#define mm_debug printk
mm_debug("allocate_user_page(0x%lx, 0x%lx, 0x%lx)\n", pd, vaddress,=
=20
alloc_page);
pgd =3D __pgd_offset(pd, vaddress);
if(!pgd_present(*pgd) || !(*pgd)){
pud_t* pud_entry =3D (pud_t*)get_free_pages_atomic(PUD_ORDE=
R);
if(!pud_entry) return 0;
*pgd =3D __pa(pud_entry) & PAGE_MASK;
mm_debug("!pgd_present, pgd: 0x%lx, *pgd: 0x%lx\n", pgd,=20
*pgd);
}
pud =3D pud_offset(pgd, vaddress);
if(!pud_present(*pud) || !(*pud)){
pmd_t* pmd_entry =3D (pmd_t*)get_free_pages_atomic(PMD_ORDE=
R);
if(!pmd_entry) return 0;
*pud =3D __pa(pmd_entry) & PAGE_MASK;
mm_debug("!pud_present, pud: 0x%lx, *pud: 0x%lx\n", pud,=20
*pud);
}
pmd =3D pmd_offset(pud, vaddress);
if(!pmd_present(*pmd) || !(*pmd)){
pte_t* pte_entry =3D (pte_t*)get_free_pages_atomic(PTE_ORDE=
R);
if(!pte_entry) return 0;
*pmd =3D __pa(pte_entry) & PAGE_MASK;
*pmd |=3D _PMD_PRESENT;
mm_debug("!pmd_present, pmd: 0x%lx, *pmd: 0x%lx\n", pmd,=20
*pmd);
}
pte =3D pte_offset(pmd, vaddress);
if(!pte_present(*pte) || !(*pte) || pte_none(*pte)){
unsigned long pfn;
page =3D get_free_pages_atomic(PAGE_ORDER);
mm_debug("page: 0x%lx\n", page);
pfn =3D __pa(page) & PAGE_MASK;
mm_debug("pfn: 0x%lx\n", pfn);
set_pte_at(current->mm, page, pte, pfn_pte(pfn >> PAGE_SHIF=
T,=20
__pgprot(PAGE_SHARED_X)));
mm_debug("pte_present now?: %lld\n", pte_present(*pte));
mm_debug("!pte_present, pte: 0x%lx\n", pte);
}
mm_debug("allocate_user_page: return 0x%lx\n", page);
#undef mm_debug
return page;
}
=2D-=20
Wang, Baojun =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0Lanzhou University
Distributed & Embedded System Lab =A0 =A0 =A0 =A0 =A0 =A0 =A0http://dslab.l=
zu.edu.cn
School of Information Science and Engeneering =A0 =A0 =A0 =A0wangbj@lzu.edu=
=2Ecn
Tianshui South Road 222. Lanzhou 730000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 .P.R.China
Tel:+86-931-8912025 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0Fax:+86-931-8912022
^ permalink raw reply
* dtc: data.c doesn't need to include dtc-parser.tab.h
From: David Gibson @ 2007-10-22 4:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Presumably we used this #include once, but it's certainly not
necessary now.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2007-10-22 14:03:09.000000000 +1000
+++ dtc/data.c 2007-10-22 14:03:44.000000000 +1000
@@ -19,7 +19,6 @@
*/
#include "dtc.h"
-#include "dtc-parser.tab.h"
void fixup_free(struct fixup *f)
{
--
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: ppc manual paging question
From: Nicholas Mc Guire @ 2007-10-22 4:40 UTC (permalink / raw)
To: Wang, Baojun
Cc: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, Miguel Masmano,
linux-embedded
In-Reply-To: <393088111.08518@eyou.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> I've got some qeustion about ppc(ppc44x) paging:
>
> how can I manually map a virtual address to a physical address through a
> specific pgd? How does ppc translate virt address to physical one? I think
> besides from tlb, the CPU will search the page table entries via the pgd, can
> I alter the pgd value to change the memory translation? under i386, it's very
> simple, we can just rewrite %%cr3, it even could invalidate all tlb entries
> automatically, how can I do this under ppc? I've tried rewrite
> current->mm->pgd and current->thread.pgdir, but sounds like it still not
> insufficiant, am I missing something vital?
>
sur ! same thing flush the tlb
or you will be totally inconsistant - actually the box should not
have survived this treatment in a stable manner. You might want to
look at kernel/ppc-stub.c as a good reference - its a similar problem
gdb also writes into memory without the kernel knowing about it - that
is comparable to what XM is doing - the solution flush the cache/tlb
all over the place - now flushing the cache is evil - but I would do
it for now and we can check alternatives and optimizations later - for
now brute force is the way to go.
for 4xx dont forget to isync after fidling with pgd/pte (see set_context
in entry_4xx.S . As far as I understand 4xx all you would really need to
do is clear the TLB entry and then you get an exception and that is
handled via 0x1100/0x1200 D/I respectively (head_4xx.S) - admitedly Im
not up to this task - need to give the manuals a lock my self to
understand whats going on there ;)
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHHCmpnU7rXZKfY2oRAjLmAJ90QwCBHLaglOfJ5QAnJyCCIZDmGwCgh/fD
E76Ki1FdfofUSuVBXL1tG0M=
=/1C5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 4:50 UTC (permalink / raw)
To: Wang, Baojun
Cc: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, Miguel Masmano,
linux-embedded
In-Reply-To: <200710221203.24157.wangbj@lzu.edu.cn>
On Mon, 2007-10-22 at 12:03 +0800, Wang, Baojun wrote:
> hi,
>
> I've got some qeustion about ppc(ppc44x) paging:
>
> how can I manually map a virtual address to a physical address through a
> specific pgd? How does ppc translate virt address to physical one? I think
> besides from tlb, the CPU will search the page table entries via the pgd, can
> I alter the pgd value to change the memory translation? under i386, it's very
> simple, we can just rewrite %%cr3, it even could invalidate all tlb entries
> automatically, how can I do this under ppc? I've tried rewrite
> current->mm->pgd and current->thread.pgdir, but sounds like it still not
> insufficiant, am I missing something vital?
What the heck are you trying to do ? Please explain and I'll tell you
how to do it properly :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ppc manual paging question
From: Wang, Baojun @ 2007-10-22 5:50 UTC (permalink / raw)
To: benh, linuxppc-dev, Miguel Masmano, rtlinuxgpl
In-Reply-To: <393029235.18964@lzu.edu.cn>
On Monday 22 October 2007 12:50:52, Benjamin Herrenschmidt wrote=EF=BC=9A
> On Mon, 2007-10-22 at 12:03 +0800, Wang, Baojun wrote:
> > hi,
> >
> > I've got some qeustion about ppc(ppc44x) paging:
> >
> > how can I manually map a virtual address to a physical address through a
> > specific pgd? How does ppc translate virt address to physical one? I
> > think besides from tlb, the CPU will search the page table entries via
> > the pgd, can I alter the pgd value to change the memory translation?
> > under i386, it's very simple, we can just rewrite %%cr3, it even could
> > invalidate all tlb entries automatically, how can I do this under ppc?
> > I've tried rewrite
> > current->mm->pgd and current->thread.pgdir, but sounds like it still not
> > insufficiant, am I missing something vital?
>
> What the heck are you trying to do ? Please explain and I'll tell you
> how to do it properly :-)
I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) fro=
m=20
x86 to ppc, I think I'm near the ending except the above problem. xtratum i=
s=20
doing things like xen but it's much simpler (it's aimed for realtime), it=20
need provides memory space sperations for it's domains, so I need manually=
=20
paging. Each domain is loaded by a userspace program (instead of the root=20
domain as a kernel module), the loader will load the domain's (ELF staticly=
=20
excutable) PT_LOAD section into memory, and then raise a properly system ca=
ll=20
(passing the structurized loaded data as arguments) to load the domain via=
=20
load_domain_sys(), and at the last step of loading the domain, xtratum will=
=20
jump to the entry code of the new domain(asm wrappered start() routine) and=
=20
then everything should be fine. The problem now is as follow:
under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, but I=
=20
guess there is something wrong with my mm code so after the domain is loade=
d,=20
the virt addres 0x100000a0 just point to garbage instead of the right start=
()=20
routine. So how can I setup paging properly so that the virtual memory coul=
d=20
be translated to proper data?
I can describe in more detail if neccessary.
Thanks very much for take care.
Regards,
Wang
P.S:
The orignal xtratum (x86) code:
#define load_pd(pd) {\
__asm__ __volatile__ ("movl %0,%%cr3": :"r" (__pa(pd))); \
}
#define save_pd(pd) {\
__asm__ __volatile__ ("movl %%cr3, %0\n\t": "=3Dr" (pd) :); \
pd =3D (unsigned long) __va (pd); \
}
=2E..
// Virtual address to page directory entry
#define va2pd(vaddress) ((vaddress) >> PGDIR_SHIFT)
// Virtual address to page table entry
#define va2pt(vaddress) (((vaddress) & 0x3FF000) >> PAGE_SHIFT)
// Page directory and page table to virtual address
#define pdpt2va(pd, pt) (((pd) << PGDIR_SHIFT) | ((pt) << PAGE_SHIFT))
// Next macro allows to obtain a pt address through the page directory
#define get_pd_addr(pd, pd_entry) \
((unsigned long) __va (((unsigned long *)(pd)) [(pd_entry)] & PAGE_MASK))
// And the following one allows to obtain a page address via the page
// table
#define get_pt_addr(pt, pt_entry) \
((unsigned long)__va (((unsigned long *)*(pt)) [(pt_entry)] & PAGE_MASK))
=2E..
static inline void fill_pd_entry (unsigned long pd,
unsigned long pd_entry,
unsigned long pt,
unsigned long flags) {
((unsigned long *)pd) [pd_entry] =3D
((__pa (pt) & PAGE_MASK) | (flags & 0xFFF));
}
static inline void fill_pt_entry (unsigned long pt,
unsigned long pt_entry,
unsigned long page,
unsigned long flags) {
((unsigned long *)pt) [pt_entry] =3D
((__pa (page) & PAGE_MASK) | (flags & 0xFFF));
}
=2E..
static inline unsigned long create_page_directory (unsigned long
(*alloc_page) (void)) {
unsigned long pd =3D (*alloc_page) (), c_pd;
if (!pd) return pd;
save_pd(c_pd);
memset ((unsigned char *) &((unsigned long *) pd)[0],
0, 1024 * sizeof (unsigned long));
memcpy ((unsigned char *) &((unsigned long *) pd)[va2pd(PAGE_OFFSET)],
(unsigned char *) &((unsigned long *) c_pd)[va2pd(PAGE_OFFSET)],
(1024 - va2pd(PAGE_OFFSET)) * sizeof (unsigned long));
return pd;
}
static inline unsigned long allocate_user_page (unsigned long pd,
unsigned long vaddress,
unsigned long (*alloc_page)
(void)) {
unsigned long pt_entry =3D va2pt(vaddress),
pd_entry =3D va2pd(vaddress), pt, page =3D 0;
if (vaddress >=3D PAGE_OFFSET) return 0;
// Check if there is already an allocated pt in the pd table
if (!(((unsigned long *)pd) [pd_entry] & _PAGE_PRESENT)) {
if (!(pt =3D (unsigned long) (*alloc_page) ())) return 0;
fill_pd_entry (pd, pd_entry,
pt, _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
} else
pt =3D get_pd_addr(pd, pd_entry);
// Check whether there is already an allocated page in the pt table
if (!(((unsigned long *)pt)[pt_entry] & _PAGE_PRESENT)) {
if (!(page =3D (unsigned long) (*alloc_page) ())) return 0;
fill_pt_entry (pt, pt_entry, page,
_PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
}
return page;
}
> Cheers,
> Ben.
=2D-=20
Wang, Baojun =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Lanzhou University
Distributed & Embedded System Lab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0http://dslab.lzu.edu.cn
School of Information Science and Engeneering =C2=A0 =C2=A0 =C2=A0 =C2=A0wa=
ngbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .P.R.China
Tel:+86-931-8912025 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fax:+86-931-8912022
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 6:01 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <200710221350.31688.wangbj@lzu.edu.cn>
> I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) from
> x86 to ppc, I think I'm near the ending except the above problem. xtratum is
> doing things like xen but it's much simpler (it's aimed for realtime), it
> need provides memory space sperations for it's domains, so I need manually
> paging. Each domain is loaded by a userspace program (instead of the root
> domain as a kernel module), the loader will load the domain's (ELF staticly
> excutable) PT_LOAD section into memory, and then raise a properly system call
> (passing the structurized loaded data as arguments) to load the domain via
> load_domain_sys(), and at the last step of loading the domain, xtratum will
> jump to the entry code of the new domain(asm wrappered start() routine) and
> then everything should be fine. The problem now is as follow:
>
> under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, but I
> guess there is something wrong with my mm code so after the domain is loaded,
> the virt addres 0x100000a0 just point to garbage instead of the right start()
> routine. So how can I setup paging properly so that the virtual memory could
> be translated to proper data?
Are you aware that the 440 MMU doesn't actually know what a page table
is and doesn't load PTEs from memory ?
It's a software loaded TLB, you'll have to put translations in the TLB
yourself. You'll need to design your own data structures for that, tho
you can use a page table for tracking, like we do in linux, and then
have your own TLB miss handler to fill the TLB from that.
Your initial code probably need to bolt a TLB entry for the kernel
itself.
Ben.
^ permalink raw reply
* Re: ppc manual paging question
From: Wang, Baojun @ 2007-10-22 6:17 UTC (permalink / raw)
To: benh, linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <393033430.04221@lzu.edu.cn>
On Monday 22 October 2007 14:01:33, Benjamin Herrenschmidt wrote=EF=BC=9A
> > I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org)
> > from x86 to ppc, I think I'm near the ending except the above problem.
> > xtratum is doing things like xen but it's much simpler (it's aimed for
> > realtime), it need provides memory space sperations for it's domains, so
> > I need manually paging. Each domain is loaded by a userspace program
> > (instead of the root domain as a kernel module), the loader will load t=
he
> > domain's (ELF staticly excutable) PT_LOAD section into memory, and then
> > raise a properly system call (passing the structurized loaded data as
> > arguments) to load the domain via load_domain_sys(), and at the last st=
ep
> > of loading the domain, xtratum will jump to the entry code of the new
> > domain(asm wrappered start() routine) and then everything should be fin=
e.
> > The problem now is as follow:
> >
> > under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, b=
ut
> > I guess there is something wrong with my mm code so after the domain is
> > loaded, the virt addres 0x100000a0 just point to garbage instead of the
> > right start() routine. So how can I setup paging properly so that the
> > virtual memory could be translated to proper data?
>
> Are you aware that the 440 MMU doesn't actually know what a page table
> is and doesn't load PTEs from memory ?
Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's=20
almost nothing like in ppc 4xx/44x.
> It's a software loaded TLB, you'll have to put translations in the TLB
> yourself. You'll need to design your own data structures for that, tho
> you can use a page table for tracking, like we do in linux, and then
> have your own TLB miss handler to fill the TLB from that.
OK, Shall I look for the DataTLBError code in head.S? I realized that I've =
got=20
DataTLBError sometimes via BDI2000/kgdb (the fault address is within=20
DataTLBError), Shall I should also look for arch/ppc/mm/fault.c?
> Your initial code probably need to bolt a TLB entry for the kernel
> itself.
I don't understand this clearly, how can I do this?
> Ben.
Regards,
Wang
=2D-=20
Wang, Baojun =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Lanzhou University
Distributed & Embedded System Lab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0http://dslab.lzu.edu.cn
School of Information Science and Engeneering =C2=A0 =C2=A0 =C2=A0 =C2=A0wa=
ngbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .P.R.China
Tel:+86-931-8912025 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fax:+86-931-8912022
^ 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