All,
Looking for tech data on the EVO/HTC devices.
Ex. What kernel they are using?
What is the base linux distro they mod'd?
What is the filesystem layout? EXT3, XFS, etc
How is the directory structure/boot sequence?
What boot loader is used?
What language are the apps using?
thx
Ex. What kernel they are using?
[email protected] #1
What is the base linux distro they mod'd?
2.6.29
What is the filesystem layout? EXT3, XFS, etc
ext3
How is the directory structure/boot sequence?
What boot loader is used?
What language are the apps using?
ENGLISH - oh tech language - java
Related
I'm trying to make an ext2 partition on my sdcard (to try out Ubuntu), using Htc branded Magic e.g. 32A board.
The kernel doesn't have any ext2 support and as you know Htc git repo is not the same as shipped kernel but it has same version and i spouse the kernel modules should work so is there any one who has ext2.ko file to share.
If ext2 needs more files to be initialized by the kernel you can share them too .
I guess the modules made for 32B should work if the kernel is 2.6.27.xxxx
Hi!
Someone could post a link to RFS sources or modules to make mountable in linux? I use ubuntu but can't find anything...
Thanks
HaDeSz
Those are closed source.
The sources maybe, but the loadable modules not!
www[dot]samsung[dot]com/global/business/semiconductor/products/fusionmemory/Products_FAQs_RFS.html (cannot post links... )
"
Q 03. Is Linux RFS an open source?
A 03. RFS package includes two parts - bootloader and kernel modules.
The former includes Tiny-Bml that is a GPL code.
Therefore you can open this code.
The latter includes three kinds of modules ; Tiny-bml, RFS and XSR. Tiny-bml is a GPL code that should be statically linked into kernel and root file system that is stored into OneNAND can be initialized using this.
Both XSR and RFS are non-GPL codes that should be dynamically linked into kernel using insmod after root file system was initialized.
In conclusion, Tiny-Bml that is included in both U-boot and Kernel is an open source code. And both XSR and RFS should be built as a module not to open."
So i think we could use it...
rfs_fat.ko is in the cpio file of the zImage
extract the ko file from the zImage. there is a cpio image that has kernel modules and one of them is the rfs_fat.ko file.
Can anyone please recommend me (or maybe cook me) a ROM which has the following capabilities:
- has System V IPC enabled in the kernel, either as a module or built-in
- made for TF101 B70
- based on ICS
- rooted
What I'm trying to do is: I have a chrooted Ubuntu environment (not dual-boot, just chroot), and I'm trying to run PostgreSQL in that, but it requires System V IPC. Plan B is to dual-boot, but I'm sooooo happy with this chrooted environment, and enjoying the best of two OSes in parallel that it's a last resort only.
Thanks in advance for all responses!
I'm amazed you're able to tolerate the lag of chroot, but I think you have to dualboot to flash a kernel over your ubuntu install, or rebuild your ubuntu image file with the kernel. Sadly I don't think one with ALL of the standard unix communications (EG. SystemVIPC) has been built.
hi all,
i'm going to support multiple android roms loading in my kernel_chooser + root_chooser project.
in few words it will be a powerful bootloader for android.
this is what it will be able to do ( many points are yet working ):
kernel loading thought kexec
boot from external devices
boot from subfolders
custom background
change android /sytem partition
change android /data partition
wipe android /cache partition
what i'm asking to you it's to make your android rom's kernel kexec-ready, applying them a kexec guest patch.
thus to make them ready to load for me.
if not i have to patch your kernel every time you modify it.
kernel_chooser and root_chooser are hosted here: https://github.com/tux-mind/tf201-dev
they are made for the asus transformer prime ( TF201 ), but they can run on any android device with your help.
i will add you to the github collaborators if you want to help.
now we are working on multiple android roms support.
thanks in advance for your time.
-- tux_mind
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
HTCDreamOn said:
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
Click to expand...
Click to collapse
thanks
yes, this should work for all devices, except for a little tuning of the partition with the configuration data ( /data ).
i have to make it to self-detect the /data partition.
let's say for example that you want to use it on your HTC Vision.
i have to build an host kernel by the stock one applying the host kexec patch.
than i have to build an android boot image which contains kernel_chooser as initrd and the above kernel.
this android boot image will be written to your current one though fastboot.
after that kernel_chooser will be able to load any kernel patched with the guest patch.
obviously the loaded kernel must be made for that device
it can also load a custom initrd and use a custom kernel CMDLINE.
so, after i made a HTC Vision kernel_chooser, your rom it's ready to load if you applied the guest patch to you kernel.
i can't explain well how to make you rom "bootable" because we are developing this
but if your kernel is kexec-loadable it will be supported by kernel_chooser.
i will update you in the next days
bye!
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
dtrail1 said:
how different are the methods to use kexec?
Click to expand...
Click to collapse
kexec it's a syscall, so it's the same on every arm device.
HTCDreamOn said:
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
Click to expand...
Click to collapse
there is a good explaination here:
http://forum.xda-developers.com/showthread.php?t=2104706
look at the "Compatibility patch".
for my tf201 the guest patch is this: http://git.lilstevie.geek.nz/?p=ubu...ch;h=54c2e480682afb0629f3854dfea4154f528421e5
which is almost the same...
i hope that almost all kernels have the same host/guest patch, in order to save us a lot of work.
the patch isn't need for kexec, but for hardboot kexec, thus to physically shutdown and restart the device with your kernel, from 0.
the standard kexec it's a assembly jump to 0 ( jmp 0x0 ) with the new kernel loaded in the .text section.
but the standard method don't reinitialize the devices and many other things that could rest in a undefined state.
btw, i have almost done my work.....i'm fighting the android udev which is overwriting my symlinks..
see you!
i got it!
my initial target was to remove devices created by ueventd and replace them with symlink to loop devices.
but android respawn ueventd and replaces my symlinks...
i tried to start the android ueventd, leave it running, and replace the /sbin/ueventd with a infinite sleep static program
but android dont' start at all..i can't even access via adb.
so, the "final" solution is to edit the /fstab.$hardware, which should be in any andoird boot image ( right ? ).
please feel free to suggest any other way to hack the mount process.
you can find the sources here: https://github.com/tux-mind/tf201-dev/tree/master/android_chooser
the program read the paths from kernel cmdline.
the syntax is that:
Code:
newandroid=blkdev:initrd_path:fstab_path
where
blkdev is the linux name of the blockdevice containing the next args ( e.g. /dev/mmcblk0p8 )
initrd_path is the path on the previous blockdevice of the android initrd ( gzipped or not )
fstab_path is the path on the previous blockdevice of the fstab file
the fstab file have this syntax:
Code:
/android/mountpoint /path/to/image/file
where
/android/mountpoint is the android mountpoint to overwrite ( e.g. /system )
/path/to/image/file is the path to the filesystem image file ( on blkdev ) ( e.g. /boot/unrooted.img )
i don't make any documentation until i will be sure that there is no better way to do this.
thanks in advance for your testing
ah, some other useful info.
because we are in testing the program write a log file with some debug info in the root of your blkdev.
so you will find /android_chooser.log on your blkdev with these info in case of errors.
tux_mind
Please
dtrail1 said:
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
Click to expand...
Click to collapse
Dtrail could you explain me kexec and its components required for loading new kernel because my device(electrify 2) is similar to droid razr. Using bmm kexec is boot able because I had checked by flashing droid razr's kernel which gave a boot loop.
I would be pleased and thankful to you if you help me.
Hello!
I'm trying to run debian on P500, but not chrooted below android. I want the reverse.
I followed this guide strictly:
http://whiteboard.ping.se/Android/Debian
Everything went well, no apparent errors. The only trouble is: the system doesn't boot I can't explain why. I'll write exactly what I did, so maybe you can help me to find what I'm doing wrong.
## Partitioning the SD card
I partitioned it in 4 partitions using fdisk, and created filesystems with mkfs:
sdb1 - ~2GB vfat (for android)
sdb2 - ~1GB ext4 (for /data - I'll mount /data here after everything is working)
sdb3 - ~12GB ext4 (for debian root filesystem)
sdb4 - ~1GB swap area
## Creating the new initramfs
I used cm-11-RC7 as base. I extracted the boot.img using unmkbootimg, a tool provided by the author of the guide, which gave me a initramfs.cpio.gz file and a zImage file.
I did exactly as described in the guide, but using busybox-armv6l (downloaded from http://busybox.net/downloads/binaries/latest/) and changing /dev/mmcblk1p2 to /dev/mmcblk0p3 (this is how my P500 called my sdb3 partition) in the /init file.
Everything went well, and I got a boot.img with busybox and the modified /init file.
## Creating the Debian filesystem
I did exactly as described in the guide, changing only the debian version (--foreign sid) and the mirror (from ftp.se to ftp.br).
Everything ok, I can use debian at this point, but chrooted below android.
## Creating the new Android root file system
I extracted the original initramfs to /android on debian filesystem and created the log/ subdirectory, as described in the guide.
## Finishing scripts
I removed the /etc/init/ folder and all files in /dev of the debian root filesystem; and created the files /etc/init, /etc/init.stage2 and /etc/rc.local as described in the guide.
## Installing the boot.img
Since I can't put my phone in fastboot mode (home+power has no effect, and I can't use LGMDP because I'm running linux) I tried two ways:
- Using the Flash Image GUI (http://forum.xda-developers.com/showthread.php?t=2086361)
This works, I got a "Success" output after flashing the modified boot.img.
- Changing the original boot.img file by the modified boot.img in the rom zip
This works, the rom is installed succesfully.
## Using it
That's where I can't explain. After flashing the modified boot.img (or modified zip rom) I reboot the phone, and got this bootloop:
LG screen > screen turns off > hardware buttons light turns off > LG screen
... and so on, forever.
What am I doing wrong?
Thanks a lot!
------------------------------------------
I could not make this work yet, but I would like to say thanks to:
Google (for android)
CyanogenMod (for the great system they provide)
AndroidARMv6 team and all developers of our beloved P500 (for making dreams possible )
Mikael Q Kuisma (for the great guide and tools - http://whiteboard.ping.se/Android/Debian)
joeykrim (for the Flash Image GUI - http://forum.xda-developers.com/showthread.php?t=2086361)
Possible problems
I think that the possible problems would be:
- Wrong busybox version
I tried with the busybox extarcted from the ROM (/system/xbin). Same result.
- ROM incompatibility
I tried the same procedure using as base CM11-RC7, Omni-4.4.3-NightlyBuild, CM10.2.0, CM10.1.6, CM9.2.3, AOKP-4.0-Beta6, CM7 and the original rom. Nothing.
I can't see the reason for this not to work...