* 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
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 21:06 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420203848.GA23192@gate.ebshome.net>
> > 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.
Unfortunately, he has to do things a bit differently. He can't afford to
have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
a reserved pool. Last I looked at our coherent code, it didn't reserve
memory at all, just address space, thus assuming the CPU can handle
having both a caheable and a non-cacheable mapping of the same pages...
(On 6xx this is deadly even if you don't access those cacheable pages
because the CPU prefetch may do it for you).
Ben.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 21:10 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060420210201.GA25755@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 14:02:01 -0700
>
> 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).
Well, Freescale's PPC programming environment manual clearly states that
this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
that this implementation will not work for the reasons I mentioned before.
The approach I'm trying to implement was his idea, so I have to trust in
him.
regards,
Gerhard
--
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 21:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <1145567174.4517.1.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> Unfortunately, he has to do things a bit differently. He can't afford to
> have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> a reserved pool. Last I looked at our coherent code, it didn't reserve
> memory at all, just address space, thus assuming the CPU can handle
> having both a caheable and a non-cacheable mapping of the same pages...
> (On 6xx this is deadly even if you don't access those cacheable pages
> because the CPU prefetch may do it for you).
Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
prefetch beyond page boundary?
So far, all "prefetching" I saw which broke non-coherent DMA was not
due to the CPU doing prefetching, but _software_ prefetching being
too aggressive.
--
Eugene
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 21:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Gerhard Pircher, linuxppc-dev,
debian-powerpc
In-Reply-To: <20060420211321.GB25755@gate.ebshome.net>
On Thu, Apr 20, 2006 at 02:13:21PM -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, he has to do things a bit differently. He can't afford to
> > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > memory at all, just address space, thus assuming the CPU can handle
> > having both a caheable and a non-cacheable mapping of the same pages...
> > (On 6xx this is deadly even if you don't access those cacheable pages
> > because the CPU prefetch may do it for you).
>
> Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> prefetch beyond page boundary?
>
> So far, all "prefetching" I saw which broke non-coherent DMA was not
> due to the CPU doing prefetching, but _software_ prefetching being
> too aggressive.
Even if this "prefetching" problem is real, instead of implementing
separate pool for allocations which will be quite rare at best, just
allocate guard space before your consistent memory and stop worrying
about it.
--
Eugene
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <1145567174.4517.1.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> (On 6xx this is deadly even if you don't access those cacheable pages
> because the CPU prefetch may do it for you).
Here is another thought if this "prefetch" theory is correct.
You guys seems to focus on
dma_alloc_coherent()/pci_alloc_consistent(), but forgeting about so
called "streaming" mappings.
You cannot just flush/invalidate cache any more, because "CPU can
prefetch this data back". So, to be completely correct (if you insist
on "6xx can prefetch"-theory), you have to actually _copy_ data to
your consistent memory on dma_map_single(). You can imagine
performance implications. I suspect even 440 will be faster in this
case than G4 :).
--
Eugene
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145567025.17087.77.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 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: Fri, 21 Apr 2006 07:03:45 +1000
>
> 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.
I hope not. But I think the AmigaOne floppy driver is copied from the i386
architecture and this one uses DMA IIRC. On the side: who uses floppy drives
these days?
> > 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.
Thanks! I was searching a while for an example, but couldn't found one.
> > 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.
Okay. Or is there a general slab allocator implementation in the Linux
kernel?
> > 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.
That's good to hear. Makes my life a little bit easier. ;-)
Thanks,
Gerhard
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
^ 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:37 UTC (permalink / raw)
To: Alessandro Rubini; +Cc: linuxppc-embedded
In-Reply-To: <20060420211120.GA3546@mail.gnudd.com>
Flashing by myself means that I cannot use the mtd drivers? Then I cannot
erase the flash as usual but I should reproduce in the application the
algorithm to erase it, isn't it?
Bye,
Antonio.
P.S: I cannot believe that the author of the best book I've ever read,
answered my question.
On Thursday 20 April 2006 23:11, Alessandro Rubini wrote:
> > but there is a chance that something bad could happen.
>
> If you mlockall(2) and sched_setscheduler(SCHED_FIFO) you can be
> somewhat confident that nothing bad can happen. However, you should flash
> by yourself (in the application, without resorting to the kernel.
>
> But please remember that Denk is right most of the time.
>
> /alessandro
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Eugene Surovegin @ 2006-04-20 21:55 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <10026.1145567455@www088.gmx.net>
On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> Well, Freescale's PPC programming environment manual clearly states that
> this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
> that this implementation will not work for the reasons I mentioned before.
> The approach I'm trying to implement was his idea, so I have to trust in
> him.
Well, you aren't the first person who tries to run G4 with
CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
that those people had to implement anything as complex as you are
trying to do.
You can try asking on #mklinux. It always better to ask people who
actually _did_ this :).
In fact, I just grepped 2.6 and found
#ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
Good luck.
--
Eugene
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 22:08 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060420215514.GE25755@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 14:55:14 -0700
>
> Well, you aren't the first person who tries to run G4 with
> CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> that those people had to implement anything as complex as you are
> trying to do.
Maybe these systems have cache coherent northbridges, which is not the case
for the AmigaOne and its "famous" ArticiaS northbridge.
> You can try asking on #mklinux. It always better to ask people who
> actually _did_ this :).
>
> In fact, I just grepped 2.6 and found
> #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
Hmm, strange. AFAIK the NOT_COHERENT_CACHE config option is available only
for the 4xx and 8xx platforms. Wouldn't the config option depend on
CONFIG_6XX too, if there are not cache coherent systems with G4 cpus?
At least I could not compile in the dma-mapping.c file without modifying the
Kconfig file.
> Good luck.
Thanks!
Gerhard
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gabriel Paubert @ 2006-04-20 22:07 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).
More details please what are the exact capabilities of the south and
host bridges?
I've never needed (and therefore) used floppy on my PreP boards (Motorola
MVME2[467]xx series), but they have a south bridge (WinBond) that has 32
bit DMA capability. This was specified in the PreP spec.
This may also depend on the host bridge since RAM appears at 2GB on
default PreP machines, which is an area that you can't access with
normal ISA DMA anyway. On the MVME machines, you could map PCI addresses
0-16 MB anywhere in RAM by reprogramming the host bridge.
However I actually reprogram the chipset to look like CHRP, i.e.,
1:1 mapping of RAM to PCI. This caused problems a long time
ago since sometimes DMA went to VGA video memory instead of RAM.
This was when kernels were not bloated enough to at least occupy
768kB of RAM, nowadays there is strictly no risk.
> 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?
If your memory is uncacheable, you are better off copying it to
cacheable memory. At least you are sure that you only access it
once (trying to copy with FP registers to halve the number of
accesses might be a big win, but you need to be careful).
Regards,
Gabriel
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-20 22:26 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20060420220707.GA17593@iram.es>
> --- Ursprüngliche Nachricht ---
> Von: Gabriel Paubert <paubert@iram.es>
> 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: Fri, 21 Apr 2006 00:07:08 +0200
>
> More details please what are the exact capabilities of the south and
> host bridges?
The southbridge is a VIA82C686B, which supports ISA DMA in the first 16MB.
The host bridge is a MAI ArticiaS. The ArticiaS has a bug in the snoop
signal logic and therefore does not support cache coherent DMA.
> I've never needed (and therefore) used floppy on my PreP boards (Motorola
> MVME2[467]xx series), but they have a south bridge (WinBond) that has 32
> bit DMA capability. This was specified in the PreP spec.
Oh, I thought PReP specifies only 24bit DMA. Okay, so the AmigaOne is more
like the i386 platform, just with a PPC cpu. ;-)
> This may also depend on the host bridge since RAM appears at 2GB on
> default PreP machines, which is an area that you can't access with
> normal ISA DMA anyway. On the MVME machines, you could map PCI addresses
> 0-16 MB anywhere in RAM by reprogramming the host bridge.
This is not the case for the AmigaOne. The RAM starts at physical address 0
(similar to CHRP). AFAIK the host bridge does not allow the remapping of the
address space. Maybe the southbridge can do this for DMA operation. I have
to investigate this. Thanks for the hint!
> > 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?
>
> If your memory is uncacheable, you are better off copying it to
> cacheable memory. At least you are sure that you only access it
> once (trying to copy with FP registers to halve the number of
> accesses might be a big win, but you need to be careful).
Sounds like a big performance loss. I hope this is not necessary.
Thanks,
Gerhard
--
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 22:39 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420211321.GB25755@gate.ebshome.net>
On Thu, 2006-04-20 at 14:13 -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, he has to do things a bit differently. He can't afford to
> > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > memory at all, just address space, thus assuming the CPU can handle
> > having both a caheable and a non-cacheable mapping of the same pages...
> > (On 6xx this is deadly even if you don't access those cacheable pages
> > because the CPU prefetch may do it for you).
>
> Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> prefetch beyond page boundary?
>
> So far, all "prefetching" I saw which broke non-coherent DMA was not
> due to the CPU doing prefetching, but _software_ prefetching being
> too aggressive.
Not 100% certain... we definitely have a bug with AGP on macs currently
for that reason though I yet have to isolate a crash caused by it ;)
(That is, we map AGP pages non-cacheable but they stay in the linear
mapping).
On POWER4, 970 and later, the chip guys confirmed that the problem is
real though. Not only bcs of prefetch but also speculative execution
which can cause the chip to do a load that will never actually be
executed. Imagine for example a loop walking an array, the chip might
speculatively load elements beyond the array by speculatively executing
beyond the branch that ends the loop.
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