* 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: 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: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: 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: 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: 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: 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: 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: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: [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: 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: 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: 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
* 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: 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
* 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: [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: 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
* unsuscribe
From: Juan P. Holder @ 2006-04-20 18:42 UTC (permalink / raw)
To: linuxppc-dev
unsuscribe
^ 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
* 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
* 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: 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
* [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][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
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