search for: lowmem

Hi, While following the developer mailing list, I came across "tremor-lowmem" version. I did some search of it in Xiph.org and "tremor" source code but wasn't able to find it. I would like to know if there is any separate thread for the "tremor-lowmem" version as we are working on the fixed point implementation of Vorbis code and we are looking...

On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote: > We don't plan to rely on CMA for too long. IOMMU support is on the way > and should make our life easier, although no matter the source of > memory, we will still have the issue of the lowmem mappings. When it comes to DMA memory, talking about lowmem vs highmem is utterly meaningless. The lowmem/highmem split is entirely a software concept and is completely adjustable. An extreme example is that you can boot any platform with more than 32MB of memory with 32MB of lowmem and the rema...

I checked out the lowmem-branch of Tremor from CVS but some files like synthesis.c seem to be missing on that branch. What am I doing wrong? Thanks, -Dave --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vor...

...> >>> >> Doing away with the concept of two memory areas will not get you to a >>> >> single unified address space. You would have to deal with things like >>> >> not being able to change the caching state of pages in the systems >>> >> lowmem yourself. You will still have to deal with remapping pages that >>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >>> >> right now as it only has 2GB of RAM), because it's in systems highmem, >>> >> or even in a differ...

...l not be an easy task. > >> > >> Doing away with the concept of two memory areas will not get you to a > >> single unified address space. You would have to deal with things like > >> not being able to change the caching state of pages in the systems > >> lowmem yourself. You will still have to deal with remapping pages that > >> aren't currently visible to the CPU (ok this is not an issue on Jetson > >> right now as it only has 2GB of RAM), because it's in systems highmem, > >> or even in a different LPAE area. > >...

...should just use this page allocator (which has the > > side effect of getting pages from CMA if available -> you are actually > > free to change the caching) and do away with the other allocator in the > > ARM case. > > Mm? Does it mean that CMA memory is not mapped into lowmem? That would > certainly help in the present case, but I wonder how useful it will be > once the iommu support is in place. Will also need to consider > performance of such coherent memory for e.g. user-space mappings. > > Anyway, I will experiment a bit with this tomorrow, thanks!...

Hi, Tis is kiran. I ve a project in which v have to cross compile the source code of ogg vorbis audio decoder onto EDB9302 ARM board.. Can u pls tell me the steps how to proceed or lead me to a source whr i can find the procedure... Thank u -------------- next part -------------- An HTML attachment was scrubbed... URL:

...g.uk> wrote: > On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote: >> We don't plan to rely on CMA for too long. IOMMU support is on the way >> and should make our life easier, although no matter the source of >> memory, we will still have the issue of the lowmem mappings. > > When it comes to DMA memory, talking about lowmem vs highmem is utterly > meaningless. > > The lowmem/highmem split is entirely a software concept and is completely > adjustable. An extreme example is that you can boot any platform with > more than 32MB of memory...

Add an highmem parameter to alloc_xenballooned_pages, to allow callers to request lowmem or highmem pages. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/balloon.c | 12 ++++++++---- drivers/xen/gntdev.c | 2 +- include/xen/balloon.h | 3 ++- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/xen/balloon.c b/dr...

...;> >> Doing away with the concept of two memory areas will not get you to a >>>> >> single unified address space. You would have to deal with things like >>>> >> not being able to change the caching state of pages in the systems >>>> >> lowmem yourself. You will still have to deal with remapping pages that >>>> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >>>> >> right now as it only has 2GB of RAM), because it's in systems highmem, >>>> >> or even...

...w and writing an replacement for > TTM will not be an easy task. > > Doing away with the concept of two memory areas will not get you to a > single unified address space. You would have to deal with things like > not being able to change the caching state of pages in the systems > lowmem yourself. You will still have to deal with remapping pages that > aren't currently visible to the CPU (ok this is not an issue on Jetson > right now as it only has 2GB of RAM), because it's in systems highmem, > or even in a different LPAE area. > > You really want to be sure...

...s page allocator (which has the >> > side effect of getting pages from CMA if available -> you are actually >> > free to change the caching) and do away with the other allocator in the >> > ARM case. >> >> Mm? Does it mean that CMA memory is not mapped into lowmem? That would >> certainly help in the present case, but I wonder how useful it will be >> once the iommu support is in place. Will also need to consider >> performance of such coherent memory for e.g. user-space mappings. >> >> Anyway, I will experiment a bit with this...

...09e000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fee9000 (usable) BIOS-e820: 000000001fee9000 - 0000000020000000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 0MB HIGHMEM available. 510MB LOWMEM available. ================================ - Centos-5.5 BIOS-E820 memory map is: BIOS-e820: 0000000000010000 - 000000000009e000 (usable) BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fee...

On Tue, Jun 24, 2014 at 6:25 AM, Lucas Stach <l.stach at pengutronix.de> wrote: > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst: >> op 24-06-14 14:23, Alexandre Courbot schreef: >> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: >> >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote: >>

...k. >> >> >> >> Doing away with the concept of two memory areas will not get you to a >> >> single unified address space. You would have to deal with things like >> >> not being able to change the caching state of pages in the systems >> >> lowmem yourself. You will still have to deal with remapping pages that >> >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> >> right now as it only has 2GB of RAM), because it's in systems highmem, >> >> or even in a different LPAE are...

...Special 16-bit segments - */ - - . = ALIGN(65536); - .real_mode (NOLOAD) : { - *(.real_mode) - } - HIDDEN(real_mode_seg = core_real_mode >> 4); - - . = ALIGN(65536); - .xfer_buf (NOLOAD) : { - *(.xfer_buf) - } - HIDDEN(xfer_buf_seg = core_xfer_buf >> 4); - - /* - * Used to allocate lowmem buffers from 32-bit code - */ - .lowmem (NOLOAD) : { - HIDDEN(__lowmem_start = .); - *(.lowmem) - HIDDEN(__lowmem_end = .); - } - HIDDEN(__lowmem_len = ABSOLUTE(__lowmem_end) - ABSOLUTE(__lowmem_start)); - HIDDEN(__lowmem_dwords = (__lowmem_len + 3) >> 2); - - HIDDEN(__high_clear_end = .)...

Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst: > op 24-06-14 14:23, Alexandre Courbot schreef: > > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > >> On 06/24/2014 07:33 PM, Alexandre Courbot wrote: > >>> On 06/24/2014 07:02 PM, Russell King - ARM Linux wrote: > >>>> On Tue, Jun 24, 2014 at

...ment for >> TTM will not be an easy task. >> >> Doing away with the concept of two memory areas will not get you to a >> single unified address space. You would have to deal with things like >> not being able to change the caching state of pages in the systems >> lowmem yourself. You will still have to deal with remapping pages that >> aren't currently visible to the CPU (ok this is not an issue on Jetson >> right now as it only has 2GB of RAM), because it's in systems highmem, >> or even in a different LPAE area. >> >> You re...

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

Hi all, I'm porting the Tremor code to an ARM platform. Unfortunately, we didn't use the low mem branch code for CPU performance consideration, and now I find the memory use in it is huge for the embedded system. After looking into the code, I found the header parse, especially, the codebook unpack part takes a lot of memory. Tremor decodes the codebooks to a cache to store