Related
So this is a major news for devs, if you found your AOSP / CM build doesn't work, make sure that you have the following line enabled if you are using TARGET_ARCH_VARIANT := armv7-a :
TARGET_ARCH_VARIANT_FPU := vfpv3-d16
This is due to a bug in armv7-a.mk in CM repo that automatically set FPU to neno for no reason. (btw, I have already reported the bug, so lets see it get patched or not later)
btw DO NOT change the line of TARGET_ARCH_VARIANT_FPU to vfpv3, otherwise your CM / AOSP build will not boot @ all.
The following BoardConfig.mk is used for compiling CWM on my kernels. And it is working for compiling CWM on my machine. You can edit the line such as USE_CAMERA_STUB, TARGET_NO_RADIOIMAGE or TARGET_PREBUILT_KERNEL on your own. However do not edit the line since TARGET_CPU_ABI to BOARD_FLASH_BLOCK_SIZE as they are vital and already right for our I9103.
Code:
LOCAL_PATH := $(call my-dir)
#USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/samsung/I9103/BoardConfigVendor.mk
TARGET_CPU_ABI := armeabi-v7a
TARGET_CPU_ABI2 := armeabi
TARGET_ARCH_VARIANT := armv7-a
TARGET_ARCH_VARIANT_CPU := cortex-a9
# DO NOT change the following line to vfpv3 as it is not really supported on our device!
TARGET_ARCH_VARIANT_FPU := vfpv3-d16
TARGET_CPU_SMP := true
ARCH_ARM_HAVE_TLS_REGISTER := true
TARGET_HAVE_TEGRA_ERRATA_657451 := true
TARGET_BOARD_PLATFORM := tegra
TARGET_BOARD_PLATFORM_GPU := tegra # Useless for CM7 build
TARGET_BOOTLOADER_BOARD_NAME := n1
TARGET_USERIMAGES_USE_EXT4 := true
BOARD_KERNEL_CMDLINE :=
BOARD_KERNEL_BASE := 0x10000000
BOARD_KERNEL_PAGESIZE := 2048
# fix this up by examining /proc/mtd on a running device
# Boot image size is 16384 x 512 bytes = 8388608
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00800000
# Recovery image size is 10240 x 512 bytes = 5242880
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00500000
# System image size is 1228800 x 512 bytes = 629145600
# You can double check it with fdisk -l /dev/block/mmcblk0p2
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x25800000
# User data image size is 4194304 x 512 bytes = 2147483648
# You can double check it with fdisk -l /dev/block/mmcblk0p6
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x80000000
BOARD_FLASH_BLOCK_SIZE := 2048
TARGET_PREBUILT_KERNEL := device/samsung/I9103/kernel
TARGET_NO_KERNEL := false
TARGET_NO_RECOVERY := false
TARGET_NO_BOOTLOADER := true
TARGET_NO_RADIOIMAGE := true
BOARD_HAS_NO_SELECT_BUTTON := true
# Use this flag if the board has a ext4 partition larger than 2gb
BOARD_HAS_LARGE_FILESYSTEM := true
btw I have an updated version of armv7-a.mk so that it should work on any device using armv7-a even when FPU is not defined. If your toolchain is complaing errors like the switch -mcpu is not working with -march, just remove the -mcpu switch on your own.
Code:
# Configuration for Linux on ARM.
# Generating binaries for the ARMv7-a architecture and higher
#
ARCH_ARM_HAVE_THUMB_SUPPORT := true
ARCH_ARM_HAVE_FAST_INTERWORKING := true
ARCH_ARM_HAVE_64BIT_DATA := true
ARCH_ARM_HAVE_HALFWORD_MULTIPLY := true
ARCH_ARM_HAVE_CLZ := true
ARCH_ARM_HAVE_FFS := true
ARCH_ARM_HAVE_ARMV7A := true
ifeq ($(strip $(TARGET_ARCH_VARIANT_FPU)),)
ARCH_ARM_HAVE_VFP := false
else
ARCH_ARM_HAVE_VFP := true
endif
ifeq ($(strip $(TARGET_ARCH_VARIANT_FPU)),neon)
ARCH_ARM_HAVE_NEON := true
endif
ifeq ($(strip $(TARGET_CPU_SMP)),true)
ARCH_ARM_HAVE_TLS_REGISTER := true
endif
arch_variant_cflags := \
-march=armv7-a \
-mtune=$(strip $(TARGET_ARCH_VARIANT_CPU)) \
-mcpu=$(strip $(TARGET_ARCH_VARIANT_CPU)) \
-D__ARM_ARCH_7__ \
-D__ARM_ARCH_7A__
ifeq ($(strip $(ARCH_ARM_HAVE_VFP)),true)
ifeq ($(strip $(ARCH_ARM_HAVE_NEON)),true)
arch_variant_cflags += -D__ARM_NEON__ -D__ARM_HAVE_NEON
else
arch_variant_cflags += -D__VFP_FP__ -D__ARM_HAVE_VFP
endif
arch_variant_cflags += -mfloat-abi=softfp -mfpu=$(strip $(TARGET_ARCH_VARIANT_FPU))
else
arch_variant_cflags += -mfloat-abi=soft
endif
ifeq ($(strip $(TARGET_ARCH_VARIANT_CPU)),cortex-a8)
arch_variant_ldflags := \
-Wl,--fix-cortex-a8
else
arch_variant_ldflags :=
endif
In addition, please look at the required errata for building stuffs on our device.
As our device is using an epic old ARM cpu, it means that it may have errata inside. Errata means errors on the hardware that cannot be fixed, however can be bypassed with errata patch.
In conjunction with finding the required errata patch, this is our cpuinfo
cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 999.42
processor : 1
BogoMIPS : 999.42
Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part : 0xc09
CPU revision : 0
Hardware : n1
Revision : 000d
Serial : 304d11d0943807ae
So next time when you try to make a custom kernel or port a kernel to this device, keep an eye on those errata please. Nvidia git sometimes made patch for those erratas as well.
For example, TARGET_HAVE_TEGRA_ERRATA_657451 is a config value telling that the src code to enable errata #657451 patch for our device. (And I have enabled that in our BoardConfig.mk already.)
Now though it sounds sad it works, but in that case does LG O2X's ARM also belong to our family of devices ?
.....that just kinda destroyed my hopes
This was sent from a Galaxy Ace. Problem?
'cooleagle' said:
Now though it sounds sad it works, but in that case does LG O2X's ARM also belong to our family of devices ?
Click to expand...
Click to collapse
its got the same AP20H tegra 2 processor i think
Because of this is it difficult to get ics .....
How its going to effect us......
according to Google policy company should provide s/w updates atleast for 16 months ....... So samy should provide ics update for us at that time they should correct the algorithms .... i am totally disturbed after seeing this.......
Sent from my GT-I9103 using XDA
mj.vikram said:
Because of this is it difficult to get ics .....
How its going to effect us......
according to Google policy company should provide s/w updates atleast for 16 months ....... So samy should provide ics update for us at that time they should correct the algorithms .... i am totally disturbed after seeing this.......
Sent from my GT-I9103 using XDA
Click to expand...
Click to collapse
Don't lose sleep over it. S2's design was also started in 2010.
We'll get ICS as LG O2X which has the same SOC is going to get it, moreover Samsung India has confirmed that this device is capable of being upgraded to ICS so sit tight till it arrives.
Please check the first topic again, it includes a specific change to BoardConfig.mk that allows anyone to build AOSP / CM for our board. Otherwise your CM7 won't boot from that.
UnknownzD said:
Please check the first topic again, it includes a specific change to BoardConfig.mk that allows anyone to build AOSP / CM for our board. Otherwise your CM7 won't boot from that.
Click to expand...
Click to collapse
Damn! you're good!
Where have you been all this time!
Thanks for all this good info!
UnknownzD you are Rolling in the Deep !
Hope to hear lots of goods news & info from you in near future man, keep them coming buddy . . . !
Cheers ! :beer:
FranzJesus said:
Damn! you're good!
Where have you been all this time!
Thanks for all this good info!
Click to expand...
Click to collapse
In case your build still doesn't work, create a armv7-a-test.mk file under /build/core/combo/arch/arm/ and then place the following lines into it. This is the working one that I can built CWM on top of it.
---------------------------------------------------------------------------
# Configuration for Linux on ARM.
# Generating binaries for the ARMv5TE architecture and higher
#
ARCH_ARM_HAVE_THUMB_SUPPORT := true
ARCH_ARM_HAVE_FAST_INTERWORKING := true
ARCH_ARM_HAVE_64BIT_DATA := true
ARCH_ARM_HAVE_HALFWORD_MULTIPLY := true
ARCH_ARM_HAVE_CLZ := true
ARCH_ARM_HAVE_FFS := true
ARCH_ARM_HAVE_ARMV7A := true
#ARCH_ARM_HAVE_VFP := true
# Note: Hard coding the 'tune' value here is probably not ideal,
# and a better solution should be found in the future.
#
arch_variant_cflags := \
-march=armv7-a \
-mtune=$(strip $(TARGET_ARCH_VARIANT_CPU)) \
-mcpu=$(strip $(TARGET_ARCH_VARIANT_CPU)) \
# -mfloat-abi=softfp \
# -mfpu=$(strip $(TARGET_ARCH_VARIANT_FPU)) \
-D__ARM_ARCH_7__ \
-D__ARM_ARCH_7A__
# -D__ARM_ARCH_5__ \
# -D__ARM_ARCH_5T__ \
# -D__ARM_ARCH_5E__ \
# -D__ARM_ARCH_5TE__
---------------------------------------------------------------------------
btw, you have to put the the first 2 lines into your BoardConfig.mk in order to enable it. The third line is optional unless you want enable the vfp calculation (which should be the one causing problem).
TARGET_ARCH_VARIANT := armv7-a-test
TARGET_ARCH_VARIANT_CPU := cortex-a9
TARGET_ARCH_VARIANT_FPU := vfpv3
I am still testing on what caused the problem. Seems like the vfp (floating point calculation) has a strong relationship to the halt problem.
Edited : Okay I have confirmed, the VFP part should be the one causing issue. You may want to disable it first and I will work that out later (to find where the bug is).
Where have you been Mate?? Awesome Work!! Continue!!
So I have figured out our right BoardConfig.mk. Do not change the TARGET_ARCH_VARIANT_FPU, otherwise the boot.img won't boot @ all.
LOCAL_PATH := $(call my-dir)
#USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/samsung/I9103/BoardConfigVendor.mk
TARGET_CPU_ABI := armeabi-v7a
TARGET_CPU_ABI2 := armeabi
TARGET_ARCH_VARIANT := armv7-a
TARGET_ARCH_VARIANT_CPU := cortex-a9
# DO NOT change the following line to vfpv3 as it is not supported on our device!
TARGET_ARCH_VARIANT_FPU := vfpv3-d16
TARGET_CPU_SMP := true
ARCH_ARM_HAVE_TLS_REGISTER := true
TARGET_HAVE_TEGRA_ERRATA_657451 := true
TARGET_BOARD_PLATFORM := tegra
TARGET_BOARD_PLATFORM_GPU := tegra # Useless for CM7 build
TARGET_BOOTLOADER_BOARD_NAME := n1
TARGET_USERIMAGES_USE_EXT4 := true
BOARD_KERNEL_CMDLINE :=
BOARD_KERNEL_BASE := 0x10000000
BOARD_KERNEL_PAGESIZE := 2048
# fix this up by examining /proc/mtd on a running device
# Boot image size is 16384 x 512 bytes = 8388608
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00800000
# Recovery image size is 10240 x 512 bytes = 5242880
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00500000
# System image size is 1228800 x 512 bytes = 629145600
# You can double check it with fdisk -l /dev/block/mmcblk0p2
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x25800000
# User data image size is 4194304 x 512 bytes = 2147483648
# You can double check it with fdisk -l /dev/block/mmcblk0p6
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x80000000
BOARD_FLASH_BLOCK_SIZE := 2048
TARGET_PREBUILT_KERNEL := device/samsung/I9103/kernel
TARGET_NO_KERNEL := false
TARGET_NO_RECOVERY := false
TARGET_NO_BOOTLOADER := true
TARGET_NO_RADIOIMAGE := true
BOARD_HAS_NO_SELECT_BUTTON := true
# Use this flag if the board has a ext4 partition larger than 2gb
BOARD_HAS_LARGE_FILESYSTEM := true
btw the errata fix is for our cpu and is only needed on userland (non-kernel side binary), do not remove that errata fix otherwise the SMP part doesn't work. It requires the errata patch to make it working.
UnknownzD said:
So I have figured out our right BoardConfig.mk. Do not change the TARGET_ARCH_VARIANT_FPU, otherwise the boot.img won't boot @ all.
LOCAL_PATH := $(call my-dir)
#USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/samsung/I9103/BoardConfigVendor.mk
TARGET_CPU_ABI := armeabi-v7a
TARGET_CPU_ABI2 := armeabi
TARGET_ARCH_VARIANT := armv7-a
TARGET_ARCH_VARIANT_CPU := cortex-a9
# DO NOT change the following line to vfpv3 as it is not supported on our device!
TARGET_ARCH_VARIANT_FPU := vfpv3-d16
TARGET_CPU_SMP := true
ARCH_ARM_HAVE_TLS_REGISTER := true
TARGET_HAVE_TEGRA_ERRATA_657451 := true
TARGET_BOARD_PLATFORM := tegra
TARGET_BOARD_PLATFORM_GPU := tegra # Useless for CM7 build
TARGET_BOOTLOADER_BOARD_NAME := n1
TARGET_USERIMAGES_USE_EXT4 := true
BOARD_KERNEL_CMDLINE :=
BOARD_KERNEL_BASE := 0x10000000
BOARD_KERNEL_PAGESIZE := 2048
# fix this up by examining /proc/mtd on a running device
# Boot image size is 16384 x 512 bytes = 8388608
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00800000
# Recovery image size is 10240 x 512 bytes = 5242880
# You can double check it with fdisk -l /dev/block/mmcblk0p8
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00500000
# System image size is 1228800 x 512 bytes = 629145600
# You can double check it with fdisk -l /dev/block/mmcblk0p2
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x25800000
# User data image size is 4194304 x 512 bytes = 2147483648
# You can double check it with fdisk -l /dev/block/mmcblk0p6
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x80000000
BOARD_FLASH_BLOCK_SIZE := 2048
TARGET_PREBUILT_KERNEL := device/samsung/I9103/kernel
TARGET_NO_KERNEL := false
TARGET_NO_RECOVERY := false
TARGET_NO_BOOTLOADER := true
TARGET_NO_RADIOIMAGE := true
BOARD_HAS_NO_SELECT_BUTTON := true
# Use this flag if the board has a ext4 partition larger than 2gb
BOARD_HAS_LARGE_FILESYSTEM := true
Click to expand...
Click to collapse
Compiling a CM7 build right now!!!
Will be back soon...
Thank you soo much!!
FranzJesus said:
Compiling a CM7 build right now!!!
Will be back soon...
Thank you soo much!!
Click to expand...
Click to collapse
If you guys want to see the difference between the old armv7-a.mk and my version, look it here : http://review.cyanogenmod.com/#/c/15478/1/core/combo/arch/arm/armv7-a.mk
Now I need some time to finish my CWM, by working on the ramdisk.
I have a minor update on the first post as changing the line
TARGET_ARCH_VARIANT_FPU := vfpv3
to
TARGET_ARCH_VARIANT_FPU := vfpv3-d16
That is because our device won't boot with the code compiled with -mfpu=vfpv3. Please refer to the first post for more info.
Wow you're good . My hat's off to you sire
This was sent from a Galaxy Ace. Problem?
Will the errata patch update the ARMv7 revision ?
This was sent from a Galaxy Ace. Problem?
EmoBoiix3 said:
Will the errata patch update the ARMv7 revision ?
This was sent from a Galaxy Ace. Problem?
Click to expand...
Click to collapse
The errata patch does not update the ARM revision (if you are talking the one captured from cpuinfo). That is because basically all the erratas cannot be patched as it is a hardware problem or bug. However, we can avoid such thing happens (such as errata in race condition) by applying the so called 'patch'. Therefore those patches are NOT fixing the problem at all, instead they just try to avoid it.
UnknownzD said:
The errata patch does not update the ARM revision (if you are talking the one captured from cpuinfo). That is because basically all the erratas cannot be patched as it is a hardware problem or bug. However, we can avoid such thing happens (such as errata in race condition) by applying the so called 'patch'. Therefore those patches are NOT fixing the problem at all, instead they just try to avoid it.
Click to expand...
Click to collapse
Ohh , you meant by workarounds !
[Discontinued]
Seems great, can you provide an A510 version ?
Sure, but be warned i don't own this device so this build is experimental (for now).
Wootever said:
Sure, but be warned i don't own this device so this build is experimental (for now).
Click to expand...
Click to collapse
Thanks, I will try to boot it this weekend, and if it's ok, maybe flash it
Wootever said:
Latest version 2.6 for Acer A700.
If you notice any problems, let me know.
Click to expand...
Click to collapse
Appreciate you sharing.
Just exactly, where did you get this recovery from? As I notice you have not much information on it, and nothing indicates you developed it yourself. If so, credits need to be given to the original author.
MD
The recovery is actually build by myself. The build process itself is not rather complicated, it only needs some small configuration for proper working.
Code used for A700 version:
Code:
DEVICE_RESOLUTION := 1920x1200
RECOVERY_SDCARD_ON_DATA := true
TW_INTERNAL_STORAGE_PATH := "/data/media"
TW_INTERNAL_STORAGE_MOUNT_POINT := "data"
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
For the A510 i used Shreps repo (https://github.com/Shr3ps/device_acer_a510) and created a modified cm.mk configuration file:
Code:
DEVICE_RESOLUTION := 1280x800
RECOVERY_SDCARD_ON_DATA := true
TW_INTERNAL_STORAGE_PATH := "/data/media"
TW_INTERNAL_STORAGE_MOUNT_POINT := "data"
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
Code:
## Specify phone tech before including full_phone
$(call inherit-product, vendor/cm/config/gsm.mk)
# Release name
PRODUCT_RELEASE_NAME := A510
# Boot Animation
TARGET_SCREEN_WIDTH := 1280
TARGET_SCREEN_HEIGHT := 800
# Inherit some common CM stuff.
$(call inherit-product, vendor/cm/config/common_full_tablet_wifionly.mk)
# Inherit device configuration
$(call inherit-product, device/acer/a510/full_a510.mk)
## Device identifier. This must come after all inclusions
PRODUCT_DEVICE := a510
PRODUCT_NAME := cm_a510
PRODUCT_BRAND := Acer
PRODUCT_MODEL := A510
PRODUCT_MANUFACTURER := Acer
PRODUCT_BUILD_PROP_OVERRIDES += \
PRODUCT_NAME=a510_pa_cus1 \
TARGET_DEVICE=picasso_m \
BUILD_FINGERPRINT="acer/a510_pa_cus1/picasso_m:4.1.2/JZO54K/1354108731:user/release-keys" \
PRIVATE_BUILD_DESC="a510_pa_cus1-user 4.1.2 JZ054K 1354108731 release-keys"
Wootever said:
The recovery is actually build by myself. The build process itself is not rather complicated, it only needs some small configuration for proper working.
Code used for A700 version:
Code:
DEVICE_RESOLUTION := 1920x1200
RECOVERY_SDCARD_ON_DATA := true
TW_INTERNAL_STORAGE_PATH := "/data/media"
TW_INTERNAL_STORAGE_MOUNT_POINT := "data"
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
For the A510 i used Shreps repo (https://github.com/Shr3ps/device_acer_a510) and created a modified cm.mk configuration file:
Code:
DEVICE_RESOLUTION := 1280x800
RECOVERY_SDCARD_ON_DATA := true
TW_INTERNAL_STORAGE_PATH := "/data/media"
TW_INTERNAL_STORAGE_MOUNT_POINT := "data"
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
Code:
## Specify phone tech before including full_phone
$(call inherit-product, vendor/cm/config/gsm.mk)
# Release name
PRODUCT_RELEASE_NAME := A510
# Boot Animation
TARGET_SCREEN_WIDTH := 1280
TARGET_SCREEN_HEIGHT := 800
# Inherit some common CM stuff.
$(call inherit-product, vendor/cm/config/common_full_tablet_wifionly.mk)
# Inherit device configuration
$(call inherit-product, device/acer/a510/full_a510.mk)
## Device identifier. This must come after all inclusions
PRODUCT_DEVICE := a510
PRODUCT_NAME := cm_a510
PRODUCT_BRAND := Acer
PRODUCT_MODEL := A510
PRODUCT_MANUFACTURER := Acer
PRODUCT_BUILD_PROP_OVERRIDES += \
PRODUCT_NAME=a510_pa_cus1 \
TARGET_DEVICE=picasso_m \
BUILD_FINGERPRINT="acer/a510_pa_cus1/picasso_m:4.1.2/JZO54K/1354108731:user/release-keys" \
PRIVATE_BUILD_DESC="a510_pa_cus1-user 4.1.2 JZ054K 1354108731 release-keys"
Click to expand...
Click to collapse
Thanks Mate for clearing it up
I guess I will try this out.
OP, sent you a PM.
MD
Wootever said:
Sure, but be warned i don't own this device so this build is experimental (for now).
Click to expand...
Click to collapse
is it safe regarding MMC_CAP_ERASE function? EMMC wipe?
all the best
Elibl said:
is it safe regarding MMC_CAP_ERASE function? EMMC wipe?
all the best
Click to expand...
Click to collapse
This recovery is build with the same kernel as the a700 version:
https://github.com/CyanogenMod/android_kernel_acer_t30
pawitp has already disabled MMC_CAP_ERASE to prevent a hard brick:
https://github.com/CyanogenMod/andr...mmit/c0e6ee0b15cb48395384851c931b7baf4b8dde00
There is no guarantee that you won't get any problems, but since the a510 is very similar to the a700 it should not brick your device.
Edit:
content of BoardConfigCommon.mk:
# Samsung EMMC brick bug
# Already disabled in kernel, but disable again for safety
BOARD_SUPPRESS_EMMC_WIPE := true
Click to expand...
Click to collapse
respective commit:
https://github.com/CyanogenMod/android_system_extras/commit/60c5383fd093826fb3f95f3dda4f313aa54f4f69
Wootever said:
This recovery is build with the same kernel as the a700 version:
https://github.com/CyanogenMod/android_kernel_acer_t30
pawitp has already disabled MMC_CAP_ERASE to prevent a hard brick:
https://github.com/CyanogenMod/andr...mmit/c0e6ee0b15cb48395384851c931b7baf4b8dde00
There is no guarantee that you won't get any problems, but since the a510 is very similar to the a700 it should not brick your device.
Edit:
content of BoardConfigCommon.mk:
respective commit:
https://github.com/CyanogenMod/android_system_extras/commit/60c5383fd093826fb3f95f3dda4f313aa54f4f69
Click to expand...
Click to collapse
Thanks really nice review going to test it tomorrow
All the best
Gesendet von meinem NexusHD2 mit Tapatalk 4 Beta
whats the problem with external_sd?
It worked fine in the 2.5 build by pawitp.
Code:
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
shouldn't it be /mnt/external_sd ?
nex86 said:
whats the problem with external_sd?
It worked fine in the 2.5 build by pawitp.
Code:
TW_EXTERNAL_STORAGE_PATH := "/external_sd"
TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"
shouldn't it be /mnt/external_sd ?
Click to expand...
Click to collapse
I think OP has updated the recovery according to the original post to address the issue.
The Op should respond a little quicker to issues
MD
Hate to say it mate. But on a 701 it's unable to mount basically about anything (when doing a backup). And the 700 uses the same mounting points. So not sure what's going on.
Did you make a mistake and post a wrong one in the latest download link? Because... Wow!
Also, is this for JB? Because it acts like you used an ICS kernel. That would explain all the mount point errors as I remember trying to use a JB based CWM on an ICS build.
Basically, it cannot mount most of the partitions, and get a TWRP fail.
Sorry for late response, i tested the recovery attached on my first post again and can't reproduce any of the errors you are reporting.
The recovery is based on recent kernel_acer_t30 and device_acer_a700 repositories both provided by cyanogenmod.
If you could provide a log (located on /tmp/recovery.log) i could take a closer look.
I just want everyone to know that this recovery is the only one that recognizes my 64gb MicroSDXC . CWM 6.0.2.3 and 6.0.3.1 don't.
Sent from my A700 using Tapatalk 4
Small update:
* fixed usb otg
* update twrp to latest version 2.6.3.0
* update kernel source (cm-10.2)
Wootever said:
Small update:
* fixed usb otg
* update twrp to latest version 2.6.3.0
* update kernel source (cm-10.2)
Click to expand...
Click to collapse
is this discontinued or are you still going to maintain?
TWRP 2.7.0.0
here you can test
Elibl said:
here you can test
Click to expand...
Click to collapse
Thanks, good work!
Gesendet von meinem A701 mit Tapatalk
I had try to build a sailfish(with kasan) rom for fuzzing througth the official page, but all the android-8.0.0_xx branch rom failed to boot the system after I flash into the pixel .
branch:
asop: android-8.0.0_r15
marlin: android-msm-marlin-3.18-oreo
step:
1. build kernel with kasan, and change compress type the lz4 to gz.
2. change the device/google/marlin/device-common.mk: LOCAL_KERNEL path to Image.gz-dtb file.
3. change the device/google/marlin/sailfish/BoardConfig.mk:
Code:
BOARD_KERNEL_BASE := 0x80000000
BOARD_KERNEL_PAGESIZE := 4096
-ifneq ($(filter sailfish_kasan, $(TARGET_PRODUCT)),)
BOARD_KERNEL_OFFSET := 0x80000
BOARD_KERNEL_TAGS_OFFSET := 0x02500000
BOARD_RAMDISK_OFFSET := 0x02700000
BOARD_MKBOOTIMG_ARGS := --kernel_offset $(BOARD_KERNEL_OFFSET) --ramdisk_offset $(BOARD_RAMDISK_OFFSET) --tags_offset $(BOARD_
-else
-BOARD_KERNEL_TAGS_OFFSET := 0x02000000
-BOARD_RAMDISK_OFFSET := 0x02200000
-endif
Any one build the sailfish(with KASAN), flash into Pixel and boot the system successfully ?
Or any log can show me why I boot the system failed ?
I have a big issue, I'm trying to build TWRP for a non-supported device and I get this error :
Code:
/home/matt/Bureau/TWRP/out/target/product/ac50dis/boot.img maxsize=-28630272 blocksize=18165312 total=7467008 reserve=36330624
error: /home/matt/Bureau/TWRP/out/target/product/ac50dis/boot.img too large (7467008 > [7700352 - 36330624])
build/core/Makefile:570 : la recette pour la cible « /home/matt/Bureau/TWRP/out/target/product/ac50dis/boot.img » a échouée
make: *** [/home/matt/Bureau/TWRP/out/target/product/ac50dis/boot.img] Erreur 1
make: *** Suppression du fichier « /home/matt/Bureau/TWRP/out/target/product/ac50dis/boot.img »
make: *** Attente des tâches non terminées....
#### make failed to build some targets (31 seconds) ####
My BoardConfig.mk :
Code:
USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/archos/ac50dis/BoardConfigVendor.mk
TARGET_ARCH := arm64
TARGET_ARCH_VARIANT := armv8-a
TARGET_CPU_VARIANT := generic
TARGET_CPU_ABI := arm64-v8a
TARGET_2ND_ARCH := arm
TARGET_2ND_ARCH_VARIANT := armv7-a-neon
TARGET_2ND_CPU_VARIANT := cortex-a7
TARGET_2ND_CPU_ABI := armeabi-v7a
TARGET_2ND_CPU_ABI2 := armeabi
TARGET_NO_BOOTLOADER := true
TARGET_BOARD_PLATFORM := mt6753
TARGET_CPU_SMP := true
ARCH_ARM_HAVE_TLS_REGISTER := true
TARGET_BOOTLOADER_BOARD_NAME := ac50dis
BOARD_KERNEL_CMDLINE := bootopt=64S3,32N2,64N2
BOARD_KERNEL_BASE := 0x40078000
BOARD_KERNEL_PAGESIZE := 2048
# fix this up by examining /proc/mtd on a running device
BOARD_BOOTIMAGE_PARTITION_SIZE := 7467008
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 17616077
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 1978662912
BOARD_USERDATAIMAGE_PARTITION_SIZE := 14066017894
BOARD_FLASH_BLOCK_SIZE := 17616077
TARGET_PREBUILT_KERNEL := device/archos/ac50dis/kernel
BOARD_HAS_NO_SELECT_BUTTON := true
TW_THEME := portrait_hdpi
The "BOARD_BOOTIMAGE_PARTITION_SIZE := 7467008" line isn't with the true value of the boot partition size which is usually 17616077 but even if I set this one, it doesn't work at all.
I really neet help so if you have just a clue, tell me .
PS : I'm a 16 years old french guy so if their are some mistakes, don't blame me
TikiMatt said:
I have a big issue, I'm trying to build TWRP for a non-supported device and I get this error:...
Click to expand...
Click to collapse
Your best bet is to post this question within the following thread.
https://forum.xda-developers.com/showthread.php?t=3404024
Good Luck!
~~~~~~~~~~~~~~~
I DO NOT PROVIDE SUPPORT VIA PM UNLESS ASKED/REQUESTED BY MYSELF.
PLEASE KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
# Treble
BOARD_PROPERTY_OVERRIDES_SPLIT_ENABLED := true
PRODUCT_FULL_TREBLE_OVERRIDE := true
BOARD_VNDK_VERSION := current
BOARD_VNDK_RUNTIME_DISABLE := true
What is the error?