* RE: problem with watchdog/reboot MPC5200
From: Joakim Tjernlund @ 2006-04-20 12:06 UTC (permalink / raw)
To: jgeissel, linuxppc-embedded
=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.
> org=20
> [mailto:linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se
> @ozlabs.org] On Behalf Of Arno Geissel
> Sent: 20 April 2006 13:35
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: problem with watchdog/reboot MPC5200
>=20
> Jaap-Jan,
>=20
> I'm not booting from flash. The kernel is loaded using bootp and
> the rootfs is mounted over NFS. Flash is not needed for the boot
> process at all. Fact is, that the mpc5200 watchdog timer
> does not work, if I have written something to flash while runtime of
> the system. If I have not, the reboot, which uses the watchdog,
> performs OK.
> On the other hand I would expect that the MTD package should
> know how to handle an Intel Strataflash.
>=20
> Arno
I think you need to connect your flash reset pin to the MPC reset pin so
that
the CPU reset will reset the flash as well.
Jocke
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 13:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9396B20F9@tmnt04.transmode.se>
Confirmed! Using the MPC reset pin (instead of PORESET)
solves it.
Thank you all
Arno
> You first need to e.g. write a reset cmd (0x5050) to it or connect
> the processor's hardreset line to the flash device.
> Jaap-Jan
>
> I think you need to connect your flash reset pin to the MPC reset pin so
> that
> the CPU reset will reset the flash as well.
>
> Jocke
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Michael Schmitz @ 2006-04-20 13:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <1145423962.9924.40.camel@localhost.localdomain>
> > arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> > arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> > make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
That's how far I got on my own (didn't try Bens patch yet but machine_id
is in fact still OK in the module, so exporting the necessary bits should
fix it.
Commenting out the -ENODEV return gives me working sound; didn't I mention
that?
> > However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> > define_machine(powermac) and now sound works for me with my original
> > I2C_POWERMAC=y SND_POWERMAC=m configuration.
>
> Yup, Paul has a working patch already, will be in 2.6.17 soonish.
I'll pull the current tree as soon as I'm back at the lab.
Michael
^ permalink raw reply
* powermac S900 6 slot PCI broken in 2.6.16
From: Robert Brose @ 2006-04-20 15:22 UTC (permalink / raw)
To: linuxppc-dev
The s900 has a 6 slot PCI bus. It works fine in 2.6.15. In 2.6.16 it
appears the interrupts are being assigned in an incorrect way, I get
an interrupt assignment failure on the device on the 21052 bridge.
(notice in the interrupt assignment at the end that the stuff on the
bridge is on irq 25 when it works in 2.6.15 and irq 1 when it doesn't
work in 2.6.16).
2.6.16 relevant dmesg
irq: Found primary Apple PIC /bandit/gc for 32 irqs
irq: System has 32 possible interrupts
.
.
ohci_hcd 0000:01:03.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
lspci
0000:00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
0000:00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21052 (rev 01)
0000:00:10.0 ff00: Apple Computer Inc. Grand Central I/O (rev 02)
2.6.16 /proc/interrupts
CPU0
1: 0 PMAC-PIC Edge ohci1394, ohci_hcd:usb1
2: 0 PMAC-PIC Edge MACE-txdma
3: 302 PMAC-PIC Edge MACE-rxdma
8: 0 PMAC-PIC Edge Built-in Sound out
9: 0 PMAC-PIC Edge Built-in Sound in
13: 37 PMAC-PIC Edge MESH
14: 640 PMAC-PIC Edge MACE
17: 0 PMAC-PIC Edge Built-in Sound misc
18: 18917 PMAC-PIC Edge ADB
19: 0 PMAC-PIC Edge SWIM3
23: 452 PMAC-PIC Level eth0
24: 1159 PMAC-PIC Level ide0
BAD: 0
2.6.15 /proc/interrupts
CPU0
2: 0 PMAC-PIC Edge MACE-txdma
3: 3233732 PMAC-PIC Edge MACE-rxdma
8: 0 PMAC-PIC Edge Built-in Sound out
9: 0 PMAC-PIC Edge Built-in Sound in
13: 109 PMAC-PIC Edge MESH
14: 3148467 PMAC-PIC Edge MACE
15: 4 PMAC-PIC Edge PowerMac Zilog
17: 0 PMAC-PIC Edge Built-in Sound misc
18: 18746 PMAC-PIC Edge ADB
19: 0 PMAC-PIC Edge SWIM3
23: 1123909 PMAC-PIC Level eth0
24: 403989 PMAC-PIC Level ide0
25: 9440212 PMAC-PIC Level ohci1394, ohci_hcd:usb1, r128@PCI:1:0:0
Bob
^ permalink raw reply
* Re: [PATCH] DTC - validation by device_type
From: Jon Loeliger @ 2006-04-20 15:35 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1143599612.2704.14.camel@enki.eridu>
On Tue, 2006-03-28 at 20:33, Paul Nasrat wrote:
> Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
Paul,
Sorry about the hang-time here. Couple questions.
> +static int check_network(struct node *net)
> +{
> +
> + int ok = 1;
> + struct property *prop;
> +
> + CHECK_HAVE(net, "reg");
> + CHECK_HAVE(net, "local-mac-address");
> + CHECK_HAVE(net, "mac-address");
> + CHECK_HAVE(net, "address-bits");
> +
> + return ok;
> +}
This says that all network nodes have to have all four
of those properties. It's not clear to me that they all
need to have both local-mac-address and mac-address.
Specifically, 1275 seems to indicate to me that the
mac-address property, being introduced by the open
operation, might be dynamically set at run time, rather
than passed as a config parameter from, say, U-Boot to
the kernel. Thus, it might not be necessary here.
Should this check be more like "has at least one of
local-mac-address and mac-address" instead?
> +static struct {
> + char *devtype;
> + int (*check_fn)(struct node *node);
> +} devtype_checker_table[] = {
> + {"network", check_network},
> +};
> +
> +static int check_devtypes(struct node *root)
> +{
> +
> + struct node *child;
> + struct property *prop;
> + int ok = 1;
> + int i;
> +
> + for_each_child(root, child) {
> + /* check this node */
> + if ((prop = get_property((child), ("device_type"))))
> + for (i = 0; i < ARRAY_SIZE(devtype_checker_table); i++) {
> + if (streq(prop->val.val, devtype_checker_table[i].devtype))
> + if (! devtype_checker_table[i].check_fn(child)) {
> + ok = 0;
> + break;
> + }
> + }
> + ok = check_devtypes(child);
> + }
> +
> + return ok;
> +}
> +
> static int check_root(struct node *root)
> {
> struct property *prop;
> @@ -716,6 +761,7 @@ int check_device_tree(struct node *dt)
> ok = ok && check_cpus(dt);
> ok = ok && check_memory(dt);
> ok = ok && check_chosen(dt);
> + ok = ok && check_devtypes(dt);
> if (! ok)
> return 0;
I buy the rest of this.
Thanks,
jdl
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jon Loeliger @ 2006-04-20 15:42 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1145383451.20176.9.camel@localhost.localdomain>
On Tue, 2006-04-18 at 13:04, Michael Ellerman wrote:
> > OK, I'm back to reading the list and beginning to catch
> > up some here...
> >
> > Let me see if I understand the consensus and direction:
> >
> > 1) DTC should NOT reserve its own blob space in the
> > memory map, as it does for generated ASM code now,
> > In all of this, I'm on deck for step 1) above.
I have updated the DTC to have several bug fixes:
- asm_emit_cell() little endian bug fix
- use two .long and not .quad directives
- Eliminate emitting memreserve for blob in ASM output
These updates are available here:
www.jdl.com/git_repos
and
git://ozlabs.org/srv/projects/dtc/dtc.git
Please verify and let me know of any problems!
> Nice summary :)
Thanks.
> I'm up for 3a, we should make redundant/overlapping reserves "harmless",
> by which I mean "not an error", but there should definitely be a warning
> in the dmesg - as it will _usually_ indicate a bug.
Please feel free to patch these into existence as needed! :-)
Thanks,
jdl
^ permalink raw reply
* [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Geoff Levand @ 2006-04-20 17:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
but it is defined inside "#ifdef __KERNEL__".
This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
From: Hiroaki Fuse
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: powerpc.git/include/asm-powerpc/page.h
===================================================================
--- powerpc.git.orig/include/asm-powerpc/page.h 2006-03-19 21:53:29.000000000 -0800
+++ powerpc.git/include/asm-powerpc/page.h 2006-04-19 12:30:04.000000000 -0700
@@ -10,7 +10,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#ifdef __KERNEL__
#include <linux/config.h>
#include <asm/asm-compat.h>
@@ -37,6 +36,7 @@
*/
#define PAGE_MASK (~((1 << PAGE_SHIFT) - 1))
+#ifdef __KERNEL__
/*
* KERNELBASE is the virtual address of the start of the kernel, it's often
* the same as PAGE_OFFSET, but _might not be_.
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: David Howells @ 2006-04-20 17:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4447C3BA.6050709@am.sony.com>
Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
> but it is defined inside "#ifdef __KERNEL__".
>
> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
Why do you want to do that? Userspace shouldn't be using PAGE_SIZE directly.
David
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Arnd Bergmann @ 2006-04-20 17:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <4447C3BA.6050709@am.sony.com>
On Thursday 20 April 2006 19:24, Geoff Levand wrote:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
> but it is defined inside "#ifdef __KERNEL__".
>
> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
>
> From: Hiroaki Fuse
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Nack.
It's a little harder unfortunately. First of all, the patch moves
more parts outside of __KERNEL__, like the #include <linux/config.h>,
which does not get installed into /usr/include/linux/.
More importantly, the page size is no longer constant on powerpc
across kernel builds. User space relying on a fixed size is broken.
Please look into the sysconf(3) and getpagesize(2) man pages for
how to do it correctly.
Which version of procps are you referring to anyway? This bug seems
to have been fixed back in 2001, but maybe it got reintroduced now.
Arnd <><
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Geoff Levand @ 2006-04-20 18:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200604201937.10667.arnd.bergmann@de.ibm.com>
Arnd Bergmann wrote:
> On Thursday 20 April 2006 19:24, Geoff Levand wrote:
>> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
>> but it is defined inside "#ifdef __KERNEL__".
>>
>> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
>>
>> From: Hiroaki Fuse
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>
> Nack.
>
> It's a little harder unfortunately. First of all, the patch moves
> more parts outside of __KERNEL__, like the #include <linux/config.h>,
> which does not get installed into /usr/include/linux/.
>
> More importantly, the page size is no longer constant on powerpc
> across kernel builds. User space relying on a fixed size is broken.
>
> Please look into the sysconf(3) and getpagesize(2) man pages for
> how to do it correctly.
>
> Which version of procps are you referring to anyway? This bug seems
> to have been fixed back in 2001, but maybe it got reintroduced now.
>
Sorry, procps-2.0.14. Seems the latest is at procps-3.2.6. I'll
check it.
-Geoff
^ permalink raw reply
* Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 18:57 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
Hi,
I try to implement not coherent cache/DMA support for G3/G4 processors, by
reserving some physical memory for DMA operations. The memory used for
consistent allocations (removed from the top of the physical memory below
896MB) is excluded from the BAT mapping and the pages are marked as
reserved. This seems to work just fine, although I still have to mark the
pages as cache inhibited.
Whilst working on this workaround for the AmigaOne and reading some articles
about the Linux kernel page tables and memory management, I came to the
conclusion that there may be some problems with this approach for not
coherent DMA:
1. The AmigaOne is similar to the PREP platform, i.e. DMA can only be
performed in the first 16MB for ISA devices (there's only a VIA southbridge,
no other SuperI/O IC with 32bit capable DMA controller). I guess the first
16MB cannot be reserved for not coherent DMA operation, because this memory
area is occupied by kernel data? (not to talk about the performance loss, if
the kernel data area would be excluded from the BAT mapping).
2. I'm not sure how to allocate memory for DMA operation. I think
alloc_pages() will not do the job for me, as the page tables for not
coherent DMA are reserved (SetPageReserved()) and removed from the available
lowmem. Also memory fragmentation may be a problem, if a lot DMA operations
with different buffer sizes are performed. Therefore a system could quickly
run out of memory for not coherent DMA operation, right?
Is there a way to minimize fragmentation?
3. How are DMA buffers used outside the kernel? Do user programs get a
pointer to the DMA buffer (in theory) from the device driver or is the data
copied to another buffer allocated by an user program?
Thanks!
Regards,
Gerhard
--
--
-- AmigaOne Linux kernel project:
-- http://amigaone-linux.sourceforge.net
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* unsuscribe
From: Juan P. Holder @ 2006-04-20 18:42 UTC (permalink / raw)
To: linuxppc-dev
unsuscribe
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: Antonio Di Bacco @ 2006-04-20 19:54 UTC (permalink / raw)
To: wojciech.kromer; +Cc: linuxppc-embedded
In-Reply-To: <4445E9E1.50204@dgt.com.pl>
Yes you are right, it is not a good idea to overwrite working cramfs=20
filesystem. But what happens if I download the new cramfs plus kernel in RA=
M,=20
do a checksum and then, completely in kernel mode, disabling all the=20
interrupts, I write to flash? No process could complain that I am overwriti=
ng=20
because no one is executing.
Bye,
Antonio.
On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=82:
> > Hi,
> >
> > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
> > receives the new rootfs from a web interface and then tries to write it
> > in the flash. While overwriting the old cramfs, the CGI will continue to
> > work? something weird could happen?
>
> Generally it's not a good idea to override working filesystem ( I've
> tried to do it once).
>
> You can have two separate copies of filesystem, one to work with, and
> another to overwrite, it requires more flash.
> Another way is working in initrd, it requires more RAM.
> You can also use jffs2 or jffs3 (experimental) to have read-write
> filesystem, and change applications only, not whole filesystem (be
> carefull with changing busybox or libraries!)
^ permalink raw reply
* Re: [PATCH] powerpc: Make rtas console _much_ faster
From: Ryan Arnold @ 2006-04-20 20:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20060418185534.B1ADF679F0@ozlabs.org>
On Tue, 2006-04-18 at 20:55 +0200, Michael Ellerman wrote:
> There's already code in the hvc_console driver to make the khvcd thread do
> a "quick" loop, where it just calls yield() instead of sleeping. The only code
> that triggered that behaviour was recently removed though, which I don't
> quite understand.
I think I'm the guilty part and I removed that code because it was silly
to be pushing to the tty with a partially filled buffer when we could
pack it up full. The original intention of HVC_POLL_QUICK was for
letting the TTY grok the data read from firmware. I think I was just
worried about 'off by one' errors and did it to be safe. I didn't count
on the write frequency side-effect
The hvc_console was originally quite speedy after I added khvcd (before
it was broken apart into back-end/front-end). We should review it for
performance on all platforms again in the future.
> Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
> characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
> backend. With this patch the "benchmark" takes ~2.8 seconds.
You might as well use HVC_POLL_QUICK to speed up the write. I put that
construct in for quick reading, not quick writing but it is a dead at
the moment. Maybe rename it HVC_WRITE_QUICK?
> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?
btw, there are a lot of users of hvc_console, power4 (non-interrupt
driven), power5 (interrupt-driven), cbe simulator, and rtas console.
Is it possible to make the poll frequency platform dependent?
--
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Mark A. Greer @ 2006-04-20 20:20 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1145547747.5314.126.camel@cashmere.sps.mot.com>
On Thu, Apr 20, 2006 at 10:42:28AM -0500, Jon Loeliger wrote:
> On Tue, 2006-04-18 at 13:04, Michael Ellerman wrote:
>
> > > OK, I'm back to reading the list and beginning to catch
> > > up some here...
> > >
> > > Let me see if I understand the consensus and direction:
> > >
> > > 1) DTC should NOT reserve its own blob space in the
> > > memory map, as it does for generated ASM code now,
>
> > > In all of this, I'm on deck for step 1) above.
>
> I have updated the DTC to have several bug fixes:
>
> - asm_emit_cell() little endian bug fix
> - use two .long and not .quad directives
> - Eliminate emitting memreserve for blob in ASM output
>
> These updates are available here:
>
> www.jdl.com/git_repos
> and
> git://ozlabs.org/srv/projects/dtc/dtc.git
>
> Please verify and let me know of any problems!
Hey John,
I did a quick test and the new dtc seems to work fine for my dts file.
Mark
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: White @ 2006-04-20 20:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604202154.45963.antonio.dibacco@aruba.it>
make it easy: if you start an application which do the flash and after
this a reset.. nothing should happen. I do it that way.
the application resist completly in RAM .. and all important libs are
in RAm or in Filesystem Cache.
It's only important that you pretend any Application from accessing
Datafiles or start of new application ...
Alternativly, you can put it in a reserved RAM Area ( mark it not
usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
after a reset....
But overwrite a cramfs works for me on >100 times without problems.
Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
<antonio.dibacco@aruba.it> :
> Yes you are right, it is not a good idea to overwrite working cramfs
> filesystem. But what happens if I download the new cramfs plus kernel in RAM,
> do a checksum and then, completely in kernel mode, disabling all the
> interrupts, I write to flash? No process could complain that I am overwriting
> because no one is executing.
>
> Bye,
> Antonio.
>
> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
> > > Hi,
> > >
> > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
> > > receives the new rootfs from a web interface and then tries to write it
> > > in the flash. While overwriting the old cramfs, the CGI will continue to
> > > work? something weird could happen?
> >
> > Generally it's not a good idea to override working filesystem ( I've
> > tried to do it once).
> >
> > You can have two separate copies of filesystem, one to work with, and
> > another to overwrite, it requires more flash.
> > Another way is working in initrd, it requires more RAM.
> > You can also use jffs2 or jffs3 (experimental) to have read-write
> > filesystem, and change applications only, not whole filesystem (be
> > carefull with changing busybox or libraries!)
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* question on why hvc_console calls hvc_poll() in hvc_handle_interrupt().
From: Ryan Arnold @ 2006-04-20 20:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1145563391.29313.174.camel@localhost.localdomain>
While on the topic of hvc_console; I think I saw a patch go through a
while ago that added hvc_poll() to hvc_handle_interrupt(). I can't say
I'm too pleased with that addition. I did my best to keep locking
outside of the interrupt handler.
I wonder if that change was tested on a power5 lpar system with several
secondary VSerial Server adapters (hvc1-hvcn) being hammered with data.
I'm pretty paranoid about deadlock, hence the reason for keeping locking
out of the int. handler.
--
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 20:38 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <28892.1145559466@www088.gmx.net>
On Thu, Apr 20, 2006 at 08:57:46PM +0200, Gerhard Pircher wrote:
> Hi,
>
> I try to implement not coherent cache/DMA support for G3/G4 processors, by
> reserving some physical memory for DMA operations. The memory used for
> consistent allocations (removed from the top of the physical memory below
> 896MB) is excluded from the BAT mapping and the pages are marked as
> reserved. This seems to work just fine, although I still have to mark the
> pages as cache inhibited.
>
> Whilst working on this workaround for the AmigaOne and reading some articles
> about the Linux kernel page tables and memory management, I came to the
> conclusion that there may be some problems with this approach for not
> coherent DMA:
>
> 1. The AmigaOne is similar to the PREP platform, i.e. DMA can only be
> performed in the first 16MB for ISA devices (there's only a VIA southbridge,
> no other SuperI/O IC with 32bit capable DMA controller). I guess the first
> 16MB cannot be reserved for not coherent DMA operation, because this memory
> area is occupied by kernel data? (not to talk about the performance loss, if
> the kernel data area would be excluded from the BAT mapping).
>
> 2. I'm not sure how to allocate memory for DMA operation. I think
> alloc_pages() will not do the job for me, as the page tables for not
> coherent DMA are reserved (SetPageReserved()) and removed from the available
> lowmem. Also memory fragmentation may be a problem, if a lot DMA operations
> with different buffer sizes are performed. Therefore a system could quickly
> run out of memory for not coherent DMA operation, right?
> Is there a way to minimize fragmentation?
>
> 3. How are DMA buffers used outside the kernel? Do user programs get a
> pointer to the DMA buffer (in theory) from the device driver or is the data
> copied to another buffer allocated by an user program?
There are already non-coherent cache PPC archs (8xx, 4xx) just look
how all this implemented there, don't reinvent the wheel.
Also, read Documentation/DMA-API.txt and DMA-mapping.txt
--
Eugene
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Benjamin Herrenschmidt @ 2006-04-20 20:48 UTC (permalink / raw)
To: Michael Schmitz
Cc: [ATR]Dj-Death, linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <Pine.LNX.4.44.0604201548060.12273-100000@zirkon.biophys.uni-duesseldorf.de>
On Thu, 2006-04-20 at 15:51 +0200, Michael Schmitz wrote:
> > > arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> > > arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> > > make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> > > make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> > > make: *** [arch/powerpc/platforms] Error 2
>
> That's how far I got on my own (didn't try Bens patch yet but machine_id
> is in fact still OK in the module, so exporting the necessary bits should
> fix it.
>
> Commenting out the -ENODEV return gives me working sound; didn't I mention
> that?
There is a proper patch in paulus tree.. it's basically the patch I
posted with an extern declaration at the beginning of the macro before
the EXPORT_SYMBOL.
> > > However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> > > define_machine(powermac) and now sound works for me with my original
> > > I2C_POWERMAC=y SND_POWERMAC=m configuration.
> >
> > Yup, Paul has a working patch already, will be in 2.6.17 soonish.
>
> I'll pull the current tree as soon as I'm back at the lab.
Patch isn't in yet it seems.
Ben
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 20:56 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060420203848.GA23192@gate.ebshome.net>
> --- Ursprüngliche Nachricht ---
> Von: Eugene Surovegin <ebs@ebshome.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> Datum: Thu, 20 Apr 2006 13:38:48 -0700
>
> There are already non-coherent cache PPC archs (8xx, 4xx) just look
> how all this implemented there, don't reinvent the wheel.
>
> Also, read Documentation/DMA-API.txt and DMA-mapping.txt
I know! Unfortunately this implementation does not work at all with G3/G4
PPC desktop CPUs for various reasons (for example due to the BAT mapping,
page tables with different access attributes for the same physical memory
area allocated by the consistent DMA functions, etc.).
regards,
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Benjamin Herrenschmidt @ 2006-04-20 20:59 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4447C3BA.6050709@am.sony.com>
On Thu, 2006-04-20 at 10:24 -0700, Geoff Levand wrote:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
> but it is defined inside "#ifdef __KERNEL__".
>
> This moves the PAGE_SIZE definition outside of "#ifdef __KERNEL__".
NAK. The procps package is bogus if it needs PAGE_SIZE since it can
change based on a config option...
Ben.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Antonio Di Bacco @ 2006-04-20 21:03 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: White
In-Reply-To: <20060420221801.55331e15@White64>
Yes, I also thought this too. Anything important should stay already in RAM=
=20
but there is a chance that something bad could happen. Probably the best=20
thing is what you suggested as second option but I have not so much ram. My=
=20
CGI writes the downloaded new software in RAM and then I should directly ju=
mp=20
to u-boot without leaving Linux the chance to mix things up and then u-boot=
=20
should copy the RAM to the flash. It seems a strange procedure but what els=
e=20
could be done with 4MB flash and 16 MB ram?=20
Bye,
Antonio.
On Thursday 20 April 2006 22:18, White wrote:
> make it easy: if you start an application which do the flash and after
> this a reset.. nothing should happen. I do it that way.
> the application resist completly in RAM .. and all important libs are
> in RAm or in Filesystem Cache.
> It's only important that you pretend any Application from accessing
> Datafiles or start of new application ...
>
> Alternativly, you can put it in a reserved RAM Area ( mark it not
> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> after a reset....
>
> But overwrite a cramfs works for me on >100 times without problems.
>
> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
>
> <antonio.dibacco@aruba.it> :
> > Yes you are right, it is not a good idea to overwrite working cramfs
> > filesystem. But what happens if I download the new cramfs plus kernel in
> > RAM, do a checksum and then, completely in kernel mode, disabling all t=
he
> > interrupts, I write to flash? No process could complain that I am
> > overwriting because no one is executing.
> >
> > Bye,
> > Antonio.
> >
> > On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > > Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=82:
> > > > Hi,
> > > >
> > > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs th=
at
> > > > receives the new rootfs from a web interface and then tries to write
> > > > it in the flash. While overwriting the old cramfs, the CGI will
> > > > continue to work? something weird could happen?
> > >
> > > Generally it's not a good idea to override working filesystem ( I've
> > > tried to do it once).
> > >
> > > You can have two separate copies of filesystem, one to work with, and
> > > another to overwrite, it requires more flash.
> > > Another way is working in initrd, it requires more RAM.
> > > You can also use jffs2 or jffs3 (experimental) to have read-write
> > > filesystem, and change applications only, not whole filesystem (be
> > > carefull with changing busybox or libraries!)
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 21:02 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <12655.1145566593@www088.gmx.net>
On Thu, Apr 20, 2006 at 10:56:33PM +0200, Gerhard Pircher wrote:
> > --- Urspr?ngliche Nachricht ---
> > Von: Eugene Surovegin <ebs@ebshome.net>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> > Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> > Datum: Thu, 20 Apr 2006 13:38:48 -0700
> >
> > There are already non-coherent cache PPC archs (8xx, 4xx) just look
> > how all this implemented there, don't reinvent the wheel.
> >
> > Also, read Documentation/DMA-API.txt and DMA-mapping.txt
> I know! Unfortunately this implementation does not work at all with G3/G4
> PPC desktop CPUs for various reasons (for example due to the BAT mapping,
> page tables with different access attributes for the same physical memory
> area allocated by the consistent DMA functions, etc.).
We have the same situation on 44x (all kernel memory is mapped
through several big TLBs and consistent functions allocate additional
cache-inhibited mappings for the same physical pages).
--
Eugene
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Antonio Di Bacco @ 2006-04-20 21:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: White
In-Reply-To: <200604202303.21680.antonio.dibacco@aruba.it>
How can I mark some RAM unusable by Linux at runtime? I know that it could =
be=20
done before booting but not runtime.
Bye,
Antonio.
On Thursday 20 April 2006 23:03, Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in R=
AM
> but there is a chance that something bad could happen. Probably the best
> thing is what you suggested as second option but I have not so much ram. =
My
> CGI writes the downloaded new software in RAM and then I should directly
> jump to u-boot without leaving Linux the chance to mix things up and then
> u-boot should copy the RAM to the flash. It seems a strange procedure but
> what else could be done with 4MB flash and 16 MB ram?
>
> Bye,
> Antonio.
>
> On Thursday 20 April 2006 22:18, White wrote:
> > make it easy: if you start an application which do the flash and after
> > this a reset.. nothing should happen. I do it that way.
> > the application resist completly in RAM .. and all important libs are
> > in RAm or in Filesystem Cache.
> > It's only important that you pretend any Application from accessing
> > Datafiles or start of new application ...
> >
> > Alternativly, you can put it in a reserved RAM Area ( mark it not
> > usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> > after a reset....
> >
> > But overwrite a cramfs works for me on >100 times without problems.
> >
> > Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
> >
> > <antonio.dibacco@aruba.it> :
> > > Yes you are right, it is not a good idea to overwrite working cramfs
> > > filesystem. But what happens if I download the new cramfs plus kernel
> > > in RAM, do a checksum and then, completely in kernel mode, disabling
> > > all the interrupts, I write to flash? No process could complain that I
> > > am overwriting because no one is executing.
> > >
> > > Bye,
> > > Antonio.
> > >
> > > On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
> > > > Dnia 2006-04-06 22:38, U=C5=BCytkownik Antonio Di Bacco napisa=C5=
=82:
> > > > > Hi,
> > > > >
> > > > > how could I upgrade my cramfs rootfs? I have a CGI in the rootfs
> > > > > that receives the new rootfs from a web interface and then tries =
to
> > > > > write it in the flash. While overwriting the old cramfs, the CGI
> > > > > will continue to work? something weird could happen?
> > > >
> > > > Generally it's not a good idea to override working filesystem ( I've
> > > > tried to do it once).
> > > >
> > > > You can have two separate copies of filesystem, one to work with, a=
nd
> > > > another to overwrite, it requires more flash.
> > > > Another way is working in initrd, it requires more RAM.
> > > > You can also use jffs2 or jffs3 (experimental) to have read-write
> > > > filesystem, and change applications only, not whole filesystem (be
> > > > carefull with changing busybox or libraries!)
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 21:03 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <28892.1145559466@www088.gmx.net>
On Thu, 2006-04-20 at 20:57 +0200, Gerhard Pircher wrote:
> 1. The AmigaOne is similar to the PREP platform, i.e. DMA can only be
> performed in the first 16MB for ISA devices (there's only a VIA southbridge,
> no other SuperI/O IC with 32bit capable DMA controller). I guess the first
> 16MB cannot be reserved for not coherent DMA operation, because this memory
> area is occupied by kernel data? (not to talk about the performance loss, if
> the kernel data area would be excluded from the BAT mapping).
Yeah that would suck. Are you sure you need ISA DMA ? You can do pseudo
DMA like pegasos for the floppy. Anything else should be able to do 32
bits DMA unless you have a very broken chipset.
> 2. I'm not sure how to allocate memory for DMA operation. I think
> alloc_pages() will not do the job for me, as the page tables for not
> coherent DMA are reserved (SetPageReserved()) and removed from the available
> lowmem.
alloc_pages() ? How so ? No, you want to allocate from your reserved
pool, you'll have to implement your own allocator. Easiest is a running
bitmap, look at ppc64 iommu code for an example.
> Also memory fragmentation may be a problem, if a lot DMA operations
> with different buffer sizes are performed. Therefore a system could quickly
> run out of memory for not coherent DMA operation, right?
> Is there a way to minimize fragmentation?
Best you can do is have separate pools for small and big allocations I
suppose.
> 3. How are DMA buffers used outside the kernel? Do user programs get a
> pointer to the DMA buffer (in theory) from the device driver or is the data
> copied to another buffer allocated by an user program?
There are cases where some drivers try that but you should ignore it for
the moment. Won't happen in most cases.
Ben.
^ 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