Ok, credit here right up front, even though we are at the bottom of the WebPage.
Team members Flyhalf(David), Bunchies(Jordan) and Reven Tech(Beau) were majorly instrumental in this. Flyhalf found
the "holiday" stuff and presented it. Bunchies modified one of his kernels with the memory values
list below and we found that we could double the number of vids with those values -but- it still failed... only
now after a count of 6(six) instead of 3(three). Then later both Bunchies and the Reven helped me setup my 'first'
github. My own kernel hub. This was on Oct 2nd, 2014.
What I had suspected before has become a fact. Need to modify the Vigor Kernel code
in order to fix the Camcorder. They were messing with the PMEM vs ION earlier in the Jelly Bean code and I think
a little in this KitKat code. -BUT- either interest was lost by those in the know -or- they just got frustrated
and gave up. At any rate, the code is incomplete -and-, consequently, has errors.
Now then, we have finally been able to get our Eclipse operational -and- we have a
Vigor Kernel Project in it. First thing we learned is that some of the "include" files that we are
concerned with are "conditionally" included. Had a hard time finding just what the conditional
include icon 
meant, or represented. It was NOT discussed anywhere that we could find. What it means is: the condition has NOT been
met so the file will NOT be included. Now then, we don't know IF it is because the proper include paths are not set
in Eclipse -or- IF the condition is intentionally NOT set. So, we have a new challenge.
The condition that we are interested in is: CONFIG_ANDROID_PMEM and it is set in include file:
autoconf.h. This file is "conditionally" included via the Makefile in /home/ctaylor/vigor/vigor_aosp_kernel.
Hmmmmm... gots lots of conditions here.
/home/ctaylor/vigor/vigor_aosp_kernel/arch/arm/mach-msm/board-vigor.c
#ifdef CONFIG_ANDROID_PMEM
#include <linux/android_pmem.h>
#endif
/home/ctaylor/vigor/vigor_aosp_kernel/include/generated/autoconf.h
#define CONFIG_ANDROID_PMEM 1
/home/ctaylor/vigor/vigor_aosp_kernel/Makefile
# Use LINUXINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
LINUXINCLUDE := -I$(srctree)/arch/$(hdr-arch)/include \
-Iarch/$(hdr-arch)/include/generated -Iinclude \
$(if $(KBUILD_SRC), -I$(srctree)/include) \
-include include/generated/autoconf.h
Ok now, I got hung up on that previous define for a number of reasons, one of which is the
fact that we will be concerned with how the PMEM vs ION is handled. Another is learning how this code is laid out and
another is learning to use Eclipse and the other tools that I have available to accomplish this task. Must use these tools and the
PC screen cause the board-vigor.c file mentioned above is over 8,000 lines long!! That would be approximately 133 pages of
print!! So, we will use these tools and maybe, maybe print out a selected page or two.
Well now, golly, the "Eclipse Project Explorer" can show you one heck of a lot of information.
More than I was prepared for, at the time. When you click on the 'plus' sign beside the file, it will start listing the contents of
it right there in the Explorer section! Have to be careful what you click on in this thing. Course here in the beginnings I'm thinking
they got a lot -but- NOT necessarily what I want... or at least not at the moment in my undertandings.
Alllllrighty ... One of the things I wanted to do was look at the Pyramid Kernel code and compare it
to our Vigor Kernel code. They are close to the same... close, so's we should be able to "steal" some code and/or ideas from
them to get ours to work ... cause ... they had the same problem.
OK, right off the bat they have the same conditional include as above. -BUT- that is code here taken from
CyanogenMod and NOT Sultan's personal stuff. Looking at his personal stuff and I see it is NOT the same!!
CONFIG_ION_MSM is in 4 files:
/home/ctaylor/Android/Sultan/sultan-kernel-pyramid-pure/arch/arm/mach-msm/board-pyramid.c
This one conditionally includes two files. Late in code conditionally includes &ion_dev as part of struct_platform.
/home/ctaylor/Android/Sultan/sultan-kernel-pyramid-pure/drivers/gpu/ion/msm/ion_cp_common.h
This one just picks a dynamic function -or- a static one. Same function just different type.
/home/ctaylor/Android/Sultan/sultan-kernel-pyramid-pure/arch/arm/configs/Sultan_defconfig
This is where it is defined.
/home/ctaylor/Android/Sultan/sultan-kernel-pyramid-pure/drivers/gpu/ion/Makefile
In this... explained below.
Ok, the Makefile is NOT conditional; it is absolute:
obj-$(CONFIG_ION) += ion.o ion_heap.o ion_system_heap.o ion_carveout_heap.o ion_iommu_heap.o ion_cp_heap.o
obj-$(CONFIG_CMA) += ion_cma_heap.o
obj-$(CONFIG_ION_TEGRA) += tegra/
obj-$(CONFIG_ION_MSM) += msm/
-But- it does show some files involved in the ION stuff. More input!! (
as in info, knowledge)
However, I'm not sure why it has the Tegra in there. Think it might be one or the other, MSM or TEGRA.
These are in both.
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion.c
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion_heap.c
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion_system_heap.c
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion_carveout_heap.c
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion_iommu_heap.c
/home/ctaylor/vigor/vigor_aosp_kernel/drivers/gpu/ion/ion_cp_heap.c
This one is NOT in the Vigor files.
/home/ctaylor/Android/Sultan/sultan-kernel-pyramid-pure/drivers/gpu/ion/ion_cma_heap.c
First 2 changes which are in memory. Actually doubles the space for the memory so we
get twice the number of recordings. Six instead of three.... Wow.
The following values are found in: /home/ctaylor/vigor/vigor_aosp_kernel/arch/arm/mach-msm/board-vigor.h
#define KERNEL_SMI_SIZE 0xE00000
#define SIZE_ADDR1 0x32000000
Made changes to board-vigor.c and board-vigor.h based on the board-holiday changes. There were lots more than
just the above two memory changes. There were some changes concerning vidc -but- they kinda bounced back and
forth on the code. Think I have all, or at least most of the changes in there. We'll soon find out.
December 8th, 2014/1:46am KERNEL_SMI_SIZE is used in board-vigor.h where it
is defined... and then in board-vigor.c. Used in two calculations in the 'h' file.
#define KERNEL_SMI_SIZE 0xE00000
#define USER_SMI_SIZE (MSM_SMI_SIZE - KERNEL_SMI_SIZE)
#define USER_SMI_BASE (KERNEL_SMI_BASE + KERNEL_SMI_SIZE)
The resultant values are used elsewhere -but- for now we are just looking at KERNEL_SMI_SIZE. Over in board-vigor.c
it is used in a struct definition.
static struct memtype_reserve msm8x60_reserve_table[] __initdata = {
/* Kernel SMI memory pool for video core, used for firmware */
/* and encoder, decoder scratch buffers */
/* Kernel SMI memory pool should always precede the user space */
/* SMI memory pool, as the video core will use offset address */
/* from the Firmware base */
[MEMTYPE_SMI_KERNEL] = {
.start = KERNEL_SMI_BASE,
.limit = KERNEL_SMI_SIZE,
.size = KERNEL_SMI_SIZE,
.flags = MEMTYPE_FLAGS_FIXED,
},
/* User space SMI memory pool for video core */
/* used for encoder, decoder input & output buffers */
[MEMTYPE_SMI] = {
.start = USER_SMI_BASE,
.limit = USER_SMI_SIZE,
.flags = MEMTYPE_FLAGS_FIXED,
},
[MEMTYPE_SMI_ION] = {
.start = MSM_ION_MM_BASE,
.limit = MSM_ION_MM_SIZE,
.flags = MEMTYPE_FLAGS_FIXED,
},
[MEMTYPE_EBI0] = {
.flags = MEMTYPE_FLAGS_1M_ALIGN,
},
[MEMTYPE_EBI1] = {
.flags = MEMTYPE_FLAGS_1M_ALIGN,
},
};
Now then, the following file list, is the compilation results of my changes to the
two files at the top of the list. Unfortunately, it did not work. Boot looped the White HTC screen. Had to remove
battery to kill it. The two files at the bottom are just for reference.
-rw-r--r-- 1 ctaylor users 8409 Oct 6 23:18 board-vigor.h
-rw-r--r-- 1 ctaylor users 216507 Oct 6 23:18 board-vigor.c
-rw-r--r-- 1 ctaylor users 3839 Oct 6 22:56 .built-in.o.cmd
-rw-r--r-- 1 ctaylor users 9996373 Oct 6 22:56 built-in.o
-rw-r--r-- 1 ctaylor users 239202 Oct 6 22:56 .board-vigor.o.cmd
-rw-r--r-- 1 ctaylor users 334864 Oct 6 22:56 board-vigor.o
-rw-r--r-- 1 ctaylor users 0 Oct 6 22:56 modules.order
-rw-r--r-- 1 ctaylor users 460 Oct 6 22:56 modules.builtin
-rw-r--r-- 1 ctaylor users 229110 Oct 6 22:45 .devices-msm8x60.o.cmd
-rw-r--r-- 1 ctaylor users 172580 Oct 6 22:45 devices-msm8x60.o
-rw-r--r-- 1 ctaylor users 222524 Oct 6 21:59 .board-vigor-wifi.o.cmd
-rw-r--r-- 1 ctaylor users 80804 Oct 6 21:59 board-vigor-wifi.o
-rw-r--r-- 1 ctaylor users 38502 Oct 6 21:59 .board-vigor-mmc.o.cmd
-rw-r--r-- 1 ctaylor users 98560 Oct 6 21:59 board-vigor-mmc.o
-rw-r--r-- 1 ctaylor users 217639 Oct 6 21:59 .board-vigor-rfkill.o.cmd
-rw-r--r-- 1 ctaylor users 79488 Oct 6 21:59 board-vigor-rfkill.o
-rw-r--r-- 1 ctaylor users 37377 Oct 6 21:59 .board-vigor-audio.o.cmd
-rw-r--r-- 1 ctaylor users 99356 Oct 6 21:59 board-vigor-audio.o
-rw-r--r-- 1 ctaylor users 223159 Oct 6 21:59 .board-vigor-keypad.o.cmd
-rw-r--r-- 1 ctaylor users 86284 Oct 6 21:59 board-vigor-keypad.o
drwxr-xr-x 2 ctaylor users 4096 Oct 6 21:58 display/
-rw-r--r-- 1 ctaylor users 155237 Oct 6 15:45 board-TR-pyra2vig.c
-rw-r--r-- 1 ctaylor users 216314 Oct 6 15:06 board-vigor-sav-inc-line-chng.c
October 7th, 2014 / 7:33am Well, evidentially, to much to fast and not really
knowing what the heck I am doing. Trying to copy another phones stuff ... and it ain't workin'. Gona put it back the way it
was and ... start again.
Alllllrighty now... First thing we are gona do restore the original files "except"
the board-vigor.c file. I re-arranged the include file lines to more correspond to the board-pyramid.c file which I am trying
to imitate... and saved a copy. That is the only difference between it and the original. The second thing we are gona do is
make those two memory changes that allows us to make 6 vids instead of only 3. And save it!! May as well till I, or one of the
others, can get it fixed.
Reference: Bunchies Code
and board-holiday.h
and board-pyramid.c
October 8th, 2014 / 2:53am The above two references talk about and hold the references for our
memory "fix". I'm going to put the values here cause I still don't trust them thar remote places.
Increase SMI to 14MB from 7MB
Accommodate the extra 7MB by subtracting 7MB from Size Addr1 which was 762MB which is now 754MB
left 1MB open by setting it to 754MB instead of 755MB
-#define KERNEL_SMI_SIZE 0x700000
+#define KERNEL_SMI_SIZE 0xE00000 /* 14MB */
-#define SIZE_ADDR1 0x2FA00000
+#define SIZE_ADDR1 0x2F261568 /* 754MB */
December 3rd, 2014/12:14pm More that I found concerning our problem, which was also
a problem on other phones ... from HTC. The following was for the Pyramid phone.
HTC Pyramid
Log message
vidc: 1080p: Increase the kernel SMI memory size.
Current in-kernel SMI size is not sufficient to decode four
simultaneous H.264 sessions. Fix is to increase the in-kernel
SMI memory size.
...
1524 1524 /* SMI PMEM Region, as the video core will use offset address */
1525 1525 /* from the Firmware base */
1526 1526 #define PMEM_KERNEL_SMI_BASE (MSM_SMI_BASE)
1527 - #define PMEM_KERNEL_SMI_SIZE 0x300000
1527 + #define PMEM_KERNEL_SMI_SIZE 0x600000
1528 1528 /* User space SMI PMEM Region for video core*/
1529 1529 /* used for encoder, decoder input & output buffers */
1530 1530 #define MSM_PMEM_SMIPOOL_BASE (PMEM_KERNEL_SMI_BASE + PMEM_KERNEL_SMI_SIZE)
1531 - #define MSM_PMEM_SMIPOOL_SIZE 0x3D00000
1531 + #define MSM_PMEM_SMIPOOL_SIZE 0x3A00000
1532 1532
1533 1533 static unsigned fb_size = MSM_FB_SIZE;
1534 1534 static int __init fb_size_setup(char *p)
...
These two phones are messing around with the shared memory in order to handle the Camcorder.
-But- they, at least the Sensation/Pyramid from Sultan, claim to be using the ION memory allocation. It is a hybrid of
ION and PMEM ... I think. Believe that ours is also a hybrid -but- not enough. And I beleve that is where the problem is.
PMEM - Process memory allocator
Like ashmem, the PMEM driver allows for sharin memory between processes.
However, unlike ashmem, it allows the sharing of large chunks of physically contiguous memory regions, not virtual memory. In addition,
these memory regions may be shared between processes and drivers.
ASHMEM - Anonymous Shared Memory ;
Anonymous SHared MEMory, or ASHMEM, is a named memory block that is shared between processes that the kernel is allowed to free.
This is notable as the kernel is not allowed to free standard shared memory.
Ashmem is described as being similar to POSIX SHM "but with different behavior". For
instance, it uses reference counting to destroy memory regions when all processes referring to them have exited, and will
shrink mapped regions when all processes referring tothem have exited, and will shrink mapped regions if the system is in
need of memory. "Unpinning" a region allows it to be shrunk, whereas "pinning" a region disallows the shrinking.
Typically, a first process creates a shared memory region using ashmem, and uses Binder to share the corresponding file descriptor with
other processes with which it wishes to share the region. Dalvik's JIT code cache, for instance, is provided to Dalvik instances
through ashmem. A lot of System Server components, such as the Surface Flinger and the Audio Flinger, rely on ashmem-- through the
IMemory interface, rather than directly.
There are two sets of Android development tools; those used for Application Development and those used for Platform Development.
Android defines its own RPC/IPC (remote procedure call/inter-process communication) mechanism: Binder. Components use the in-kernel
Binder mechanism accessible accessible through /dev/binder.
OOM adjustments are set on startup by the init.rc file. Some of the properties set at build time are stored in the
/system/build.prop file. Use getprop to get the current list of properties and their values.
Shared Memory with ashmem
Ashmem - Ashmem is an Anonymous SHared
MEMory system that adds interfaces so processes can
share named blocks of memory. As an example, the
system could use Ashmem to store icons, which
multiple processes could then access when drawing
their UI. The advantage of Ashmem over traditional
Linux shared memory is that it provides a means for
the kernel to reclaim these shared memory blocks if
they are not currently in use. If a process then tries to
access a shared memory block the kernel has freed, it
will receive an error, and will then need to reallocate
the block and reload the data.
Main Differences between Android & Linux Operating Systems
ReZound Processor & Memory
- Codename: Snapdragon S3
- CPU Structure (complexity): RISC
- Width of Machine Word: 32 bit
- Primary (RAM) Data bus: 32 bit
Memory
- 16 GB internal memory
- Pre-loaded 16 GB microSD card with support for optional cards up to 32 GB.
- 1 GB of RAM (DDR2)
Physical and virtual memory
Traditionally, one has physical memory, that is, memory that
is actually present in the machine, and virtual memory, that is,
address space. Usually the virtual memory is much larger than
the physical memory, and some hardware or software mechanism
makes sure that a program can transparently use this much larger
virtual space while in fact only the physical memory is available.
Nowadays things are reversed: on the ReZound
one can have up to 48 GB of
physical memory, while addresses have 32-bits, so that the virtual
memory has a size of 4 GB. We'll have to wait for a 64-bit
architecture to get large amounts of virtual memory again.
The present situation on an Armv7 with more than 4 GB is
that using the LPAE (Large Physical Address Extension) it is possible
to place the addressable 4 GB anywhere in the available memory,
but it is impossible to have access to more than 4 GB at once.
"Borrowed"/Stolen from:
The Linux Kernel
and Extensions to the ARMv7-A Architecture
Ok, now that we have our head straight... or at least straighter... let's see IF we use this
re-learned and new knowledge and get this fixed!! For one thing... the pictures -and- the videos taken and recorded are
stored on the INTERNAL SD... NOT the External one.
CameraWrapper.cpp#L113
CameraWrapper.cpp#L167
config.xml#L37
Comments...
code
references info and usage:
obj -$(CONFIG)
Eclipse Setup for Kernel
Eclipse Icons
PMEM Persistant Memory
ION Mem Alloc
ION Mem Manager
Embedded Android
Naked Rez
Mnt Pts for Rez
Investigating Your RAM Usage
Android Kernel Features
Managing Mem
Debugging Memory
We have CIFS/NFS in our Kernel.
Camera Project
