* RE: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-20 10:26 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded list
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85964A@ismail.innsys.innovsys.com>
Rune,
> On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
> seconds, so it kept resetting before the heartbeat function got called
> on boot.
>
> I had to add a watchdog reset to time_init() because it woud pause there
> for about 2 secondfs trying to see if there was a realtime clock.
>
I think that you are OK. Using the while(1) test suggested by Paul Bilke,
I could verify that time_init() is the cause for the reset. In fact, I have
no RTC on my board (so I suppose the delay looking for it will be maximum).
Thanks
Alex Bastos
^ permalink raw reply
* Re: modules without a .toc section not loading
From: Alan Modra @ 2006-04-20 8:54 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20060420005445.GA24721@curie-int.vc.shawcable.net>
On Wed, Apr 19, 2006 at 05:54:45PM -0700, Robin H. Johnson wrote:
> On Thu, Apr 20, 2006 at 09:58:30AM +0930, Alan Modra wrote:
> > > Ideas for Solutions:
> > > 1. Either the kernel needs to realize that it does not need a .toc
> > > section (I'm uncertain about this, being new to PPC).
> > > 2. GCC is at fault, and it should be generating a .toc.
> > The former.
> Ok, so in module_64.c, under what cases is .toc NOT needed?
>
> I dug at the code, and the R_PPC_REL24 blocks need the contents of the
> .toc (via stub_for_addr -> create_stub -> my_r2), and I'm not certain
> about it.
Yes, the stubs need some reasonable r2 value.
> The R_PPC64_TOC/R_PPC64_TOC16/R_PPC64_TOC16_DS blocks shouldn't be hit
> when there isn't a .toc* from what I figure.
Yes, and finding such a reloc should trigger an error.
> If the R_PPC_REL24 block won't be hit when there isn't a .toc, the check
> in module_frob_arch_sections, lines 194-197 can just be shortened as a
> fix to the problem.
You could have an R_PPC_REL24 in a module (a function call into another
module or the kernel) without a .toc. A module without a .toc section
won't itself use r2 for anything, but the any stubs added do need r2.
I'm surprised no one has fixed this. Here's a totally untested patch
that ought to do the trick (or if it doesn't, should put you on the
right path).
--- linux-2.6.16/arch/powerpc/kernel/module_64.c~ 2006-01-18 14:17:29.000000000 +1030
+++ linux-2.6.16/arch/powerpc/kernel/module_64.c 2006-04-20 18:22:42.000000000 +0930
@@ -191,8 +191,15 @@ int module_frob_arch_sections(Elf64_Ehdr
(void *)hdr
+ sechdrs[sechdrs[i].sh_link].sh_offset);
}
- if (!me->arch.stubs_section || !me->arch.toc_section) {
- printk("%s: doesn't contain .toc or .stubs.\n", me->name);
+
+ /* If we don't have a .toc, just use .stubs. Nothing in the
+ module itself should use r2, but we need to set r2 in case
+ the module calls out to other functions. */
+ if (!me->arch.toc_section)
+ me->arch.toc_section = me->arch.stubs_section;
+
+ if (!me->arch.stubs_section) {
+ printk("%s: doesn't contain .stubs.\n", me->name);
return -ENOEXEC;
}
@@ -338,11 +345,21 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC:
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
*(unsigned long *)location = my_r2(sechdrs, me);
break;
case R_PPC64_TOC16:
- /* Subtact TOC pointer */
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC16 reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if (value + 0x8000 > 0xffff) {
printk("%s: bad TOC16 relocation (%lu)\n",
@@ -355,7 +372,12 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC16_DS:
- /* Subtact TOC pointer */
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC16_DS reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if ((value & 3) != 0 || value + 0x8000 > 0xffff) {
printk("%s: bad TOC16_DS relocation (%lu)\n",
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 9:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I have a custom board based on MPC5200 processor running
the latest linuxppc_2_4_devel.
Everything is working fine until a flash write access is performed
using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
where the watchdog timer is charged and linux waits with closed
interrupts until the MPC performs the reset. Only power off helps
in this situation.
It seems to me like a hardware problem, because the freescale
MPC5200lite reference board does not run into this.
The main difference of the custom board to the reference board
is, that it is using 16MB Intel Strada Flash instead of AMD flash,
which has an erase block size of 128kB.
Has anybody else experienced such behaviour?
Arno Geissel
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Jaap-Jan Boor @ 2006-04-20 10:21 UTC (permalink / raw)
To: jgeissel; +Cc: linuxppc-embedded
In-Reply-To: <200604201146.01342.jgeissel@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Arno,
I think your problem is related to Intel Strataflash specifics.
After a write to strataflash, it remains in status mode until another
read (or reset) command is issued. This means you don't get the flash
contents when reading it, but a status bit (e.g. 0x8080 at every spot).
So when the processor start executing after a reset, it's not reading
proper instructions.
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
On Thu, 2006-04-20 at 11:46 +0200, Arno Geissel wrote:
> Hello all,
>
> I have a custom board based on MPC5200 processor running
> the latest linuxppc_2_4_devel.
> Everything is working fine until a flash write access is performed
> using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
> where the watchdog timer is charged and linux waits with closed
> interrupts until the MPC performs the reset. Only power off helps
> in this situation.
> It seems to me like a hardware problem, because the freescale
> MPC5200lite reference board does not run into this.
> The main difference of the custom board to the reference board
> is, that it is using 16MB Intel Strada Flash instead of AMD flash,
> which has an erase block size of 128kB.
> Has anybody else experienced such behaviour?
>
> Arno Geissel
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1513 bytes --]
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 11:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1145528473.13114.6.camel@linpc041.aimsys.nl>
Jaap-Jan,
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.
Arno
> Arno,
>
> I think your problem is related to Intel Strataflash specifics.
> After a write to strataflash, it remains in status mode until another
> read (or reset) command is issued. This means you don't get the flash
> contents when reading it, but a status bit (e.g. 0x8080 at every spot).
> So when the processor start executing after a reset, it's not reading
> proper instructions.
>
> 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
>
> On Thu, 2006-04-20 at 11:46 +0200, Arno Geissel wrote:
> > Hello all,
> >
> > I have a custom board based on MPC5200 processor running
> > the latest linuxppc_2_4_devel.
> > Everything is working fine until a flash write access is performed
> > using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
> > where the watchdog timer is charged and linux waits with closed
> > interrupts until the MPC performs the reset. Only power off helps
> > in this situation.
> > It seems to me like a hardware problem, because the freescale
> > MPC5200lite reference board does not run into this.
> > The main difference of the custom board to the reference board
> > is, that it is using 16MB Intel Strada Flash instead of AMD flash,
> > which has an erase block size of 128kB.
> > Has anybody else experienced such behaviour?
> >
> > Arno Geissel
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 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
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