I bought a very weak netbook that comes preinstalled with android 2.0 which
I want to replace with another linux distro like puppy or damnSmallLinux.
the netbook has no bios menu with "boot from SD card" option so that and when I inserted an SD card or USB key with grub/lilo it still didn't bot from it.
I wasn't able to find no key sequence to enter android debugging mode so that I don't have root for the android system.
is there an android-internal way to specify boot from another media?
is there a "das-uboot" way to force android boot from another device?
thanks!
I'm not familiar with netbooks running android so here's my experience with embedded devices.
To my best knowledge there is no "android-internal" way. Android takes over after u-boot and rarely(read never) does it modify to u-boot environment partition.
To cut the long story short it's nearly impossible and it's too much effort for nothing.
Also for starters You'll need a debug serial console attached to the board or an ADB shell. It's just guess work without a shell.
For a general algorithm:
get a shell working
Get to know the system( cpu type, partition table, ...)
Now just research what you can do with the things you know.
Or the 'all or nothing' - reverse engineer the firmware upgrade and the firmware images and try to boot with your own.
Long story:
For sd_card boot you have 2 options:
use the bootloaders on the board and load the kernel and the rootfs from the sdcard
boot from sd_card
Load kernel and fs from sd_card:
There is no general u-boot way to change the boot device without changing the u-boot environment . The u-boot environment most of the time resides in a nand partition.
There may be some way coded by the manufacturer, which may be guessed by the offline firmware upgrade procedure. This is probably your best bet for a quick solution.
Try to reverse engineer that.
Boot From sd_card:
Most platforms have SYSCONFIG registers or hardware pins, operated by jumpers on development platforms and mostly hardwired on production ones.
SYSCONFIG controls the boot devices. It can be configured for NAND only or SD_CARD only, etc...
If the system is indeed configured to load from an sd_card there are a few more problems:
Some of the times the SD card has to be formated in a specific way(for ex: http://www.omappedia.org/wiki/SD_Configuration ).
Other times the first stage loader has to be signed. And it's hard figuring out what the first stage bootloader is (x-loader, or something other) and the signing part is kind of tricky :)
you have to know the exact platform configuration to build u-boot and x-loader
Related
I have android studio installed on my windows operating system 64 bit 4 gb Ram but now i want to work in linux(ubuntu 12.04)which is installed on the same windows 7 (no separate partition)where the android studio is installed so will it cause any harm to my windows operating system or any performance issues.Searched a lot about it on google but no clues.Any suggestions are highly welcome.
If you're using Dual Boot then it shouldn't slow down your system at all. Although it won't make sense to have Android Studio installed in Windows when you have it at your Linux since you might get confused on which OS you saved which project. It won't slow down your system because your Windows OS only "sees" the HD Partition for Windows, the same is the case for your Linux Partition.
That being said, Linux can only see and touch the resources in the HD allotted for Linux. And since you won't be able to run the two OS at the same time, you won't have RAM problems (which is a problem with Virtual Machines).
Also, if I am not mistaken, when you dual boot, strictly speaking, you are partitioning your Hard Drive. When you go check Windows' Drive C, it's no longer 500GB (or whatever the total size of your HD is).
This is more commonly done by placing the Linux system inside a virtual machine on the Windows system.
Many universities establish uniform Linux environments for their students this way. If you conduct a search, you may find prefabricated examples of this publicly available.
As described, it does not sound like the Linux would boot. Some sort of storage separation is required to define the operating system. If one is placed inside the other as described, it will simply be a directory held in local storage. To use it as the operating system, the CPU will need to be able to find it at boot without the help of the other system, thus the multiple partitions.
Emulated systems, like Cygwin or MinGW, will work within the context of another operating system, but they are built for that purpose. They are simulated systems with a common collection of typical commands. That gives a similar programming experience, but it doesn't fulfill the definition of an operating system because it doesn't cover CPU activity.
Virtual machines will bridge this gap by taking emulators a step further. They will simulate the CPU activity, frequently I/O controls (e.g. own MAC address for the VM under control of the VM). Virtual machines won't need a sepatate partition.
If the two Android installs are separated by one being inside a VM and the other being on the main Windows: there's no immediate reason why they would not work. If you ran the Android emulators in both, it's obvious that the one in the VM would be slower. It might be unbearably slow. There may be some competition for I/O when you start hooking up phones to the hardware. So, as a practical matter, it could get bogged down for developing simultaneously this way. Meanwhile, if the IDE fits within the VM with Linux, it could run.
Steps to solve your problem in a single intel core i3 processor with ram size 4 gb and harddisk of 1 tb is that ,
1>> just duel boot system :- here in these step you must duel boot your system with linux and window both you can found easy tutorials for doing that thing .
2>>install jdk on both of system
3>>just set path for java in both of system in linux it is not required .
4>>Now you go to https://developer.android.com/studio/index.html.and download latest version of stdio in both of partition .
5>>Now you can create android apps in both of system
My question is that is there any chance that any command in adb can damage (both hardware and software) my android phone (my phone is not rooted) and if software can it be recovered by factory reset? It is Micromax A120 and runs on android 4.4.2.
Yes, you can easily mess up your phone if you mess with ADB and don't know what you are doing. This is particularly true if you are using the 'Recovery' options (flashing new software to your device) in particular, if don't do this correctly, there are opportunities to mess things up (particularly if you are not patient, and don't wait for all operations to complete).
For the most part ADB is just a communication mechanism, and if you are careful to do only things you are confident are safe, there is minimal risk.
Bottom line, there is nothing specific about ADB that is risky, but it is a tool, and if mis-used could cause issues. Use it carefully, and you should be fine.
With adb you can delete and copy data on your mobile phone. So you can loose data or damage the Android System. However you have every time the chance to go into fastboot mode and flash a new Android ROM using the fastboot tools. You only can damage your Android device if you flash a corrupted bootloader using fastboot.
So in short form:
ADB: You can delete data but you have everytime the chance to recover your system. (However you can loose all your data!)
Fastboot: You can destroy your Android device if you flash a corrupted bootloader. It's irreparable.
I am looking for a generic way to mount windows shares via the USB cable (not WiFi). By generic, I mean a method that does not require device specific kernel modules.
If this is not achievable, I am open to other ideas but WiFi/internet connectivity is totally out of the question.
My development machine is sitting on a domain and the shares are likely to be on another machine, not necessarily local on my host machine.
Any thoughts or suggestions are greatly welcomed.
Many thanks,
P
This is not possible without kernel modules, because kernel modules are the thing that does the whole job. So your question is like "i am looking for the way to put that water into the glass, but without the glass part". So apps may offer SMB support, but that's because these apps include all the code to handle SMB inside. So if you want to mount samba share on filesystem level you need kernel module and sufficient permissions. Otherwise you just need to look for app that supports SMB and does what you want.
I'm definetly considering to use a chroot of some linux installation to implement a smb arm linux server on android, you can run all sorts of ARM linux tools inside an android machine trough chroot, once in linux there's not much you can't do, and the simplest distro available can pretty much install whatever you want. Of course, you can strip just the server binaries inside a package and run that just like an android app of some sort, or install the binaries in /system/bin and xbin in android and add some init script. Whatever rocks your boat.
BTW, my implementation involves a USB-ramdrive, i want my 2GB RAM MK809II android device to store a 1GB img file in a tmpfs ramdisk, mounted in a place accessible by all apps like /sdcard/ram/ram.img, where i can create a smb share to a windows machine, that connection will be made via USB, i'll use adb reverse to connect to the SMB share and redirect the server ports to my local tcp 7777 1137 1138 1139, my smb filesharing server has already been disabled, so these relevant ports are free to use in my pc, that's important because windows will only recognize servers running in the same ports. I'll access the smb share from windows and mount the img file in the share trough ImDisk to have my virtual
ramdrive under windows.
I have a pc with only 1.5gb of ram, and sometimes this thing run out of memory, i want to have a readyboost drive that's lightning fast compared to a solid state usb drive, i want to have usb as a bottleneck in my transfer speed..... some time ago i saw a 50MB/s usb2.0 hdd then i wondered what would happen if i can bottleneck the fck out of usb2.0, that's completely inviable via it's original solid state bottlenecked drives, but ram in the other hand has almost no speed limit... so i got my little project, out of some need and mostly curiosity. I'm chasing for a way into store the pagefile in that ramdisk, though i think windows readyboost already stores virtual memory pages in the readyboost
file.
Looking in the android source for the reboot command we find the following line:
__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, \
LINUX_REBOOT_CMD_RESTART2, argv[optind]);
Which is the standard Linux system call to reboot the system with a specific command, see Unix System Call Reboot.
In Android this command is used to tell the bootloader to start either the kernel in recovery mode or to go to the fastboot mode within the bootloader.
My question is: How does the bootloader pick up the command? And is this functionality implemented in U-Boot? (I am unable to find it searching either through Google or in the U-Boot source.)
Additionally it seems this is not specific to Android, but is the way Linux performs a "reboot with a command". Any information on how this is "normally" handled/used in Linux?
When the system is rebooted using LINUX_REBOOT_CMD_RESTART2, the supplied command string is passed to all of the notifiers registered with register_reboot_notifer(), and finally to machine_restart() - the architecture-specific function that actually performs system restart.
Most architectures ignore the passed command entirely - for an example of one that doesn't, see SPARC. The SPARC implementation of machine_restart() passes the supplied string to the boot command of the PROM.
The ARM implementation of machine_restart() ends up passing the supplied command to arch_reset() which is implemented separately on each ARM platform - from what I can see, most if not all of those implementations ignore the passed command, at least in the upstream kernel. This may not be the droid you're looking for.
Write "boot-recovery" command in MSC partiton. The bootloader reads the string from MSC partition and loads the recovery kernel. This was the way the recovery kernel was loaded in Froyo and before. The same approach can be followed in GB/HC/ICS.
Another method is to carve out some memory and pass some flag which is read from he bootloader. The only issue is that the DRAM contents might get lost during reboot unless you put SDRAM in self refesh mode. So during restart this needs to be taken care of.
First method is useful when the power goes off during the update process. In this case the device need to go into recovery kernel again. In that case MSC partition must be cleared only after whole update process is successful.
I have no clue how they do it in Android, but on our systems where we use u-boot as well we have a similar mechanism.
We reserve a very small memory portion that is reserved for "communication" from bootloader to kernel and the opposite direction as well. If this memory can survive a reboot (put the RAM in self-refresh mode before rebooting, or in Flash), it's then easy to read the value in the bootloader start and to determine if you have to start the kernel and then your system usually or you want to go to a special mode of the bootloader.
On some ARM processors the running kernel sets a flag in one of the CPU registers which is then read by UBOOT keep in mind this stuff if very hardware specific.
the camera of my mobile (running Eclair-update1) keeps being non-responsive in 90% of the time, so I assumed a hardware defect at first. After whiping the cache and the phone user data sereval times it worked again. At least for a while. Now it stopped working again.
Browsing the net I found quite some users who experience the same problem and had a hard time after whiping their user data off the device.
So my question would be: how close can I get to the hardware with the SDK? I'd like to write an app to influence hardware states (e.g. re-initializing the camera, remounting the SDcard aso.), but I'd prefer doing it - if possible - with the SDK instead of NDK.
Thanks in advance!S.
It's not a question of sdk vs. ndk, but of underlying operating system level permissions preventing ordinary (aftermarket vs. manufacturer/carrier installed) android applications in general from doing raw hardware access.
Download Android SDK to your computer
Boot device to recovery
Connect USB cable to PC
Run adb shell then
umount /data
umount /system
e2fsck -fv /dev/block/stl9
e2fsck -fv /dev/block/stl10
Taken from forum.xda-developers.com/showthread.php?t=1396366