I'm working on a device directory to get CM7 building for the Galaxy Player 5.0 USA. I'm using Entropy512's kernel and copying some things out of vzwtab mostly, but there's some parameters in the BoardConfig.mk that I'm not sure how to find out. The Galaxy Player 5.0 seems to be unique among the example galaxy-based devices I could find in having only mmc partitions. So does anyone know what the proper values should be for:
BOARD_KERNEL_BASE
BOARD_NAND_PAGE_SIZE
BOARD_FLASH_BLOCK_SIZE
BOARD_PAGE_SIZE
As far as I can tell the BOARD_KERNEL_BASE is supposed to be the offset into the boot.img where the kernel can be found? But Samsungs don't use the boot.img so does this paremeter make sense? The various samsung devices all define this value though, and with different values, so maybe it means something else..
I found this in the make file in arch/arm of Entrophy512's code.
I think this is what you need for BOARD_KERNEL_BASE ...
HTML:
# The byte offset of the kernel image in RAM from the start of RAM.
TEXT_OFFSET := $(textofs-y)
Above that textofs-y was defined as
HTML:
textofs-y := 0x00008000
textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000
# We don't want the htc bootloader to corrupt kernel during resume
textofs-$(CONFIG_PM_H1940) := 0x00108000
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
ifeq ($(CONFIG_ARCH_SA1100),y)
textofs-$(CONFIG_SA1111) := 0x00208000
endif
I think your value should be 0x00008000 ...
Thanks for that! A bit of googling on TEXT_OFFSET led me to PHYS_OFFSET, which is defined in arch/arm/mach-*/include/mach/memory.h, I think that's the value I need, it matches up in a couple of other kernels anyway. At least it matches up for galaxys2, but for mach-s5pv210 products, the PHYS_OFFSET is 0x30000000 but the kernel base is 0x32000000, I'm not sure why they don't match but I think one of those values should be galaxy player kernel base.
A quick grep turns this up...
./mach-s5pc100/include/mach/memory.h:#define PHYS_OFFSET UL(0x20000000)
s5pc100 is the name of the board for the Galaxy Player 5.0 right?
---------- Post added at 06:50 PM ---------- Previous post was at 06:08 PM ----------
HTML:
> As long as the zImage is placed within the 256MB range from the
> start of the memory, ZRELADDR (Address where the decompressed
> kernel will be placed, usually == PHYS_OFFSET + TEXT_OFFSET)
I think I may have it. It seems like we need both values PHYS_OFFSET +TEXT OFFSET.
So if that is what the BOARD_KERNEL_BASE is supposed to be then the value should be 0x20008000.
It would be nice to find a way to get the address off of our currently running devices. I'm going to look for some command or app that will say what it is.
References
http://www.spinics.net/lists/arm-kernel/msg89507.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017614.html
Meticulus said:
A quick grep turns this up...
./mach-s5pc100/include/mach/memory.h:#define PHYS_OFFSET UL(0x20000000)
s5pc100 is the name of the board for the Galaxy Player 5.0 right?
Click to expand...
Click to collapse
According to /proc/config.gz from Entropy512's kernel it's the s5pv210.
Come on Meticulous, get back in the game! We need you!
Sent from my cm_tenderloin using Tapatalk
ambrice said:
According to /proc/config.gz from Entropy512's kernel it's the s5pv210.
Click to expand...
Click to collapse
According to the build.prop (ro.build.platform) it's s5pc110. I'm betting the boards are pretty close. I'm just trying to help out. This is all new to me...
Meticulus said:
I think I may have it. It seems like we need both values PHYS_OFFSET +TEXT OFFSET.
So if that is what the BOARD_KERNEL_BASE is supposed to be then the value should be 0x20008000.
It would be nice to find a way to get the address off of our currently running devices. I'm going to look for some command or app that will say what it is.
Click to expand...
Click to collapse
The source for the unpackbootimg is at system/core/mkbootimg/unpackbootimg.c, and it has the line:
printf("BOARD_KERNEL_BASE %08x\n", header.kernel_addr - 0x00008000);
So I think in the boot.img header header.kernel_addr is the ZRELADDR and the BOARD_KERNEL_BASE is supposed to be ZRELADDR - TEXT_OFFSET, which would be the PHYS_OFFSET.
Meticulus said:
According to the build.prop (ro.build.platform) it's s5pc110. I'm betting the boards are pretty close. I'm just trying to help out. This is all new to me...
Click to expand...
Click to collapse
I definitely appreciate the help! It's all new to me too..
They are very close:
http://odroid.foros-phpbb.com/t198-differences-between-s5pc110-and-s5pv210
I downloaded the official samsung released YP-G70 sources, and the defconfig has CONFIG_ARCH_S5PV210=y. So maybe they're close enough as far as the build.prop is concerned? I'm not sure what ro.build.platform is used for..
HTML:
./unpackbootimg -i zImage
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE e19f8000
BOARD_PAGE_SIZE 24061976
Segmentation fault
It looks like that code can not unpack Entrophy512's kernel...
Also regarding the board name, look in "/system/lib/hw/". All the filenames are like "*.s5pc110.so"
I think that "s5pv210" is also the same board as the galaxy s...
I think, but am not sure, but some of those values there are placeholders on Samsung-based devices.
I was a dumbass and accidentally nuked my device tree so I need to rebuild it. I may instead just fork ambrice's to redo it.
Looks like this week/weekend will consist of some fun decobwebbing.
I would appreciate the help. My current state is that it builds an image but an assert fails when flashing the boot.img.
I've done some updates, I have a working kernel and recovery.
When I boot CM7 system_server crashes with this error:
Code:
I/Zygote ( 165): Accepting command socket connections
I/sysproc ( 223): Entered system_init()
I/sysproc ( 223): ServiceManager: 0x76d18
I/SurfaceFlinger( 223): SurfaceFlinger is starting
I/SurfaceFlinger( 223): dithering enabled
I/SurfaceFlinger( 223): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
E/HAL ( 223): load: module=/system/lib/hw/gralloc.s5pc110.so
E/HAL ( 223): Cannot load library: reloc_library[1311]: 165 cannot locate '__android_log_print'...
E/FramebufferNativeWindow( 223): Couldn't get gralloc module
system_server is linked against liblog.so which defines the __android_log_print, I think maybe this error is misleading. /system/lib/hw/gralloc.s5pc110.so is a library I pulled off the stock image as part of the vendor proprietaries.
stack trace in log shows it's crashing in android:isplayHardware::init(unsigned int) in libsurfaceflinger.so
Any ideas of things to try?
I'm just throwing this stuff out there but, assuming that "gralloc.s5pc110.so" is in the location specified, perhaps the "gralloc.s5pc110.so" is trying to locate "liblog.so" and it is "liblog.so" that is in the incorrect location (from stock). If "__android_log_print" is what it can not find and that is defined in "liblog.so" then that leads me to believe that it's not loaded and may be in the wrong location. So, you could compare the location from stock and put a duplicate there and see if that gets you any further. Maybe it's the "PATH" var in init.rc does not include the path for liblog.so...?
As a last resort you could try pulling a "gralloc.aries.so" and renaming it to match since the boards are so similar and see what that gets you?
In a couple days, I may join you on your quest to get a cm7 port. This is your project and you seem to be doing quite well but maybe I can get lucky help out.
Last night, I built my first Android kernel from source (opensource.samsung.com) - it was a great experience. However, I wasn't able to accomplish my goals.
I'm trying to build a few specific kernel modules, but I need them to be external modules (*.ko). The build works well, but from what I can tell by the modules.builtin file(s), the specific ones I'm trying to get out of this are built-in only. During the compile, it generates *.o files just fine. At the end of the compile, it shows it used MODPOST to create 17 .ko files. All of these are noted in the modules.order file(s).
It seems that no matter what I do, I can't change whether these are built-in or external. I tried modifying the modules.builtin and modules.order files (there's multiple copies of these that reference the specific modules I want), but these just seem to get overwritten at build time.
I've done lots of searching here and abroad, and I can't seem to find the magic I'm looking for. I've tried many things, most notably:
- make <path>/<module>.ko
- make modules
- other various commands
- cd into subdir that contains the modules I want, running make there (no targets)
Doing more research, it seems it might point to the Makefile that's in the subdirectory of the modules I want. I see various "hello world" Makefiles out there, but most of these don't seem to be completely relevant to what I'm trying to do - plus I already have a Makefile for these modules.
I'm assuming that what I probably need to do is modify the Makefile that's specific to these modules, to force it to make .ko files instead of .o files. I'm also assuming that I can't simply change the lines in the Makefile to read "<module>.ko" instead of "<module>.o". I realize that there's a difference in these files.
I also thought the answers might lie in looking at the Makefile of one of the other 17 external modules that get created. However, it appears these are no different than the Makefile of the modules I'm after.
Okay, enough rambling - I'll give some details now, in case they are needed. I've downloaded the I337 source (MF3) from opensource.samsung.com. The three modules I need (so far) are: msm_kgsl_core.o, msm_adreno.o, msm_z180.o. The makefile that includes these three came from <source-root>/drivers/gpu/msm, and it is attached. I may need more than these three files later, but this is a good start.
I don't want to hear a bajillion questions about, "What are you planning to do with these files?" or "Why do you need them anyway?" - the answer is a longer story than this thread. Trust me, I just need these.
So what do I need to do to make these three files? Thank you for your help.
EDIT/SOLUTION:
obj-y = built-in module
obj-m = external module
I still can't track down the source of the three variables in the last three lines of this Makefile, but they are obviously returning "y". I changed the last three lines manually to:
Code:
obj-m += msm_kgsl_core.o
obj-m += msm_adreno.o
obj-m += msm_z180.o
... and then ran a "make clean" and "make modules" again. Voilà: 20 modules built by MODPOST.
Hi guys,
I've got another one for you. I've compiled the LiME (Linux Memory Extractor) module for fun. You can use this to make a full raw RAM dump. Unlike viewmem and other utilities which are limited to /dev/mem and /dev/kmem, this will give you an unrestricted RAM dump for examination and research. You can find more information at LiME's Google Code page.
THIS MODULE WILL ONLY WORK ON THE NC2 KERNEL!
To use:
Copy lime.ko to /sdcard
Code:
insmod /sdcard/lime.ko "path=/sdcard/ram.lime format=lime"
From there you can copy via USB the dump to your computer. You can also do a TCP dump over network, but I won't explain that here. Raw format is also available, but I prefer lime for a number of reasons.
Download here
Thanks to @Surge1223 and @BeansTown106
Shout out to @darkspr1te and @E:V:A also.
And a resentful thanks to Samsung Open Source center for releasing NC4 source months later...
Enjoy!
(Sorry moderators in advance, I wasn't quite sure where to post this.)
Great! But, since you've already jumped through all the compilation hoops, perhaps you can also give a brief description how to compile this for other kernels? (or what you did on your own.)
E:V:A said:
Great! But, since you've already jumped through all the compilation hoops, perhaps you can also give a brief description how to compile this for other kernels? (or what you did on your own.)
Click to expand...
Click to collapse
That will be a rather extensive write-up, perhaps when I get some more time. That would require a tutorial on setting up an entire build environment, which as we know, doesn't always play nicely
E:V:A said:
Great! But, since you've already jumped through all the compilation hoops, perhaps you can also give a brief description how to compile this for other kernels? (or what you did on your own.)
Click to expand...
Click to collapse
cd to directory with lime source the type make after editing the makefile to reflect something similar to the one I use below. This assumes one has kernel compiled already.
Edit to reflect your build environment and make sure your paths are set up beforehand (i.e., sudo gedit ~/.bashrc , ~/.bash_profile or ~/.profile etc)
Makefile used:
obj-m := lime.o
lime-objs := tcp.o disk.o main.o
KDIR := /home/surge/android
KVER := $(shell uname -r)
PWD := $(shell pwd)
CCPATH := /home/surge/android/arm-eabi-4.7/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- EXTRA_CFLAGS=-fno-pic -C $(KDIR) M=$(PWD) modules
$(MAKE) tidy
tidy:
rm -f *.o *.mod.c Module.symvers Module.markers modules.order \.*.o.cmd \.*.ko.cmd \.*.o.drm -rf \.tmp_versions
clean:
Click to expand...
Click to collapse
Environmental variables used:
export JAVA_HOME=/usr/lib/jvm/java-7-oracle
export PATH=$PATH:$JAVA_HOME/bin
export PATH=$PATH:~/android/arm-eabi-4.7/bin
export CROSS_COMPILE=arm-eabi-
Click to expand...
Click to collapse
Sent from my SCH-I545 using XDA Premium 4 mobile app
Wait what does this do?
It makes dumps all your RAM into an image file.
Hi,
by any chance does anyone have module for Nexus 4 or 5?
Odd issue, thought maybe someone else has come across this or can guide me out of it.
So first off, here is what I am working with.
Tablet: LG G Pad V410
ROM: Lineage OS 14.1 (Most Updated Nightly Ver)
The Issue:
We have made a login app that detects a face and allows a PIN entered for login. Works great as is. The issue is this. When we add it to the build to be included as a native system app so it can be the default launcher....it still works OK, with one issue. The face detection simply stops working. We have the GApps package loaded and the play store seems to be OK, and services too for that matter.
Just the face detect stops working?
OK, so we tested this out by removing the app as a system app and then side loaded it after the device booted up. Guess what? The face detection works again like a charm, no issues at all! So what gives?
Is there some special folder or make file that I need to edit somewhere that will allow my app to work as intended when loaded as a system app?
I load the app into this area: "Lineage/packages/apps"
I also loaded it into the core.mk list found here: "Lineage/build/target/product/core.mk"
Can anyone provide some details as to where to go from here? I am searching but coming up short to it.
Thanks! :laugh:
EDIT: Here is what is in my make file for the app if its needed.
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := LoginApp
LOCAL_CERTIFICATE := platform
LOCAL_SRC_FILES := LoginApp.apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_PACKAGE_NAME := LoginApp
include $(BUILD_PREBUILT)
#THIS IS THE MAKE FILE FOR OUR TABLET APP
Now I know I've done this before. But I think I had to make an entire Application.mk file. I am trying to use either the Windows or Linux NDKr19 to build a standalone toolchain that contains ONLY the arm64 executable binaries. (essentially "aarch64-android-android" or "aarch64-android-arm64-v8a")
EDIT: So I'm dumb and figured it out. I've attached the binaries that can run on the device.