Guest rickywyatt Posted August 5, 2012 Report Posted August 5, 2012 To stop us rooting it ill be on computer soon I no that a deleted data/local/tmp/ before but I can't remember how I did it lol
Guest rickywyatt Posted August 5, 2012 Report Posted August 5, 2012 This is why I what the old update from xolo to see if thay change anything in the boot.bin
Guest Posted August 5, 2012 Report Posted August 5, 2012 (edited) maybe look through deleted files, maybe you still have them files from last time you looked at them? Many file recovery programs out there, I use the built in feature of AVG pc tuneup pro, which is first thing I did when you reminded me I uploaded the old update.zip, but it was not there, meaning I most likely done it via my device, which since that upload date had been updated to x900. Surely I was not the only one to download that update.zip? someone here must have it in their recycle bin, or could recover it from there. sods law I delete it ;) Edited August 5, 2012 by Guest
Guest joe1r23 Posted August 5, 2012 Report Posted August 5, 2012 https://www.dropbox.com/s/bh4vvl9hn8kq3um/update.zip
Guest Posted August 5, 2012 Report Posted August 5, 2012 (edited) Good man, you have redeamed my sin. :D @rickywyatt, boot.img is in there Edited August 5, 2012 by Guest
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 Is this the patch work by intel in ths link as as ddvelopers id in this mail is @ intel.com https://patchwork.kernel.org/patch/1133431/
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 I think we can contact him via mail
Guest rickywyatt Posted August 5, 2012 Report Posted August 5, 2012 yep thay did what i thought heres the new update mkdir /data/local 0751 root root mkdir /data/local/tmp 0771 shell shell heres the old mkdir /data/local 0771 shell shell mkdir /data/local/tmp 0771 shell shell
Guest Posted August 5, 2012 Report Posted August 5, 2012 lol very sneaky of them seeing as it appeares to be some camera fix, as far as I could see.
Guest rickywyatt Posted August 5, 2012 Report Posted August 5, 2012 thay must have been worryed about something to change it but what lol
Guest Posted August 5, 2012 Report Posted August 5, 2012 maybe the reason you wanted to get back in there. :lol:
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 WhT i noticed in the change is over the air update software ...the added software which was not presrnt in previous version
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 I think i got the bootloader patch development by intel https://patchwork.kernel.org/patch/1133431/
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 Android userspace tells the kernel that it wants to boot into recovery > or some other non-default OS environment by passing a string argument > to reboot(). It is left to the OEM to hook this up to their specific > bootloader. > > This driver uses the bootloader control block (BCB) in the 'misc' > partition, which is the AOSP mechanism used to communicate with > the bootloader. Writing 'bootonce-NNN' to the command field > will cause the bootloader to do a oneshot boot into an alternate > boot label NNN if it exists. The device and partition number are > passed in via kernel command line. > > It is the bootloader's job to guard against this area being uninitialzed > or containing an invalid boot label, and just boot normally if that > is the case. The bootloader will always populate a magic signature in > the BCB; the driver will refuse to update it if not present.
Guest vermat17 Posted August 5, 2012 Report Posted August 5, 2012 And is this helpful for someone trying to root the phone??? Sorry, I'm a bit of a noobie :P
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 Android userspace tells the kernel that it wants to boot into recovery or some other non-default OS environment by passing a string argument to reboot(). It is left to the OEM to hook this up to their specific bootloader. This driver uses the bootloader control block (BCB) in the 'misc' partition, which is the AOSP mechanism used to communicate with the bootloader. Writing 'bootonce-NNN' to the command field will cause the bootloader to do a oneshot boot into an alternate boot label NNN if it exists. The device and partition number are passed in via kernel command line. It is the bootloader's job to guard against this area being uninitialzed or containing an invalid boot label, and just boot normally if that is the case. The bootloader will always populate a magic signature in the BCB; the driver will refuse to update it if not present. Signed-off-by: Andrew Boie <[email protected]> ---drivers/staging/android/Kconfig | 11 ++ drivers/staging/android/Makefile | 1 + drivers/staging/android/bcb.c | 232 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 244 insertions(+) create mode 100644 drivers/staging/android/bcb.c NeilBrown - June 29, 2012, 9:25 p.m. On Fri, 29 Jun 2012 12:36:30 -0700 Andrew Boie <[email protected]> wrote: > Android userspace tells the kernel that it wants to boot into recovery > or some other non-default OS environment by passing a string argument > to reboot(). It is left to the OEM to hook this up to their specific > bootloader. > > This driver uses the bootloader control block (BCB) in the 'misc' > partition, which is the AOSP mechanism used to communicate with > the bootloader. Writing 'bootonce-NNN' to the command field > will cause the bootloader to do a oneshot boot into an alternate > boot label NNN if it exists. The device and partition number are > passed in via kernel command line. > > It is the bootloader's job to guard against this area being uninitialzed > or containing an invalid boot label, and just boot normally if that > is the case. The bootloader will always populate a magic signature in > the BCB; the driver will refuse to update it if not present. > > Signed-off-by: Andrew Boie <[email protected]> Maybe I'm missing something obvious, but why does this need to be implemented in the kernel? Can't some user-space process just write to that partition using open/read/seek/write/close before calling 'reboot'. Thanks, NeilBrown > ---> drivers/staging/android/Kconfig | 11 ++ > drivers/staging/android/Makefile | 1 + > drivers/staging/android/bcb.c | 232 ++++++++++++++++++++++++++++++++++++++ > 3 files changed, 244 insertions(+) > create mode 100644 drivers/staging/android/bcb.c > > diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig > index 9a99238..c30fd20 100644 > --- a/drivers/staging/android/Kconfig > +++ b/drivers/staging/android/Kconfig > @@ -78,6 +78,17 @@ config ANDROID_INTF_ALARM_DEV > elapsed realtime, and a non-wakeup alarm on the monotonic clock. > Also exports the alarm interface to user-space. > > +config BOOTLOADER_CONTROL > + tristate "Bootloader Control Block module" > + default n > + help > + This driver installs a reboot hook, such that if reboot() is invoked > + with a string argument NNN, "bootonce-NNN" is copied to the command > + field in the Bootloader Control Block on the /misc partition, to be > + read by the bootloader. If the string matches one of the boot labels > + defined in its configuration, it will boot once into that label. The > + device and partition number are specified on the kernel command line. > + > endif # if ANDROID > > endmenu > diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile > index 8e18d4e..a27707f 100644 > --- a/drivers/staging/android/Makefile > +++ b/drivers/staging/android/Makefile > @@ -9,5 +9,6 @@ obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER) += lowmemorykiller.o > obj-$(CONFIG_ANDROID_SWITCH) += switch/> obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o > obj-$(CONFIG_PERSISTENT_TRACER) += trace_persistent.o > +obj-$(CONFIG_BOOTLOADER_CONTROL) += bcb.o > > CFLAGS_REMOVE_trace_persistent.o = -pg > diff --git a/drivers/staging/android/bcb.c b/drivers/staging/android/bcb.c > new file mode 100644 > index 0000000..af75257 > --- /dev/null > +++ b/drivers/staging/android/bcb.c > @@ -0,0 +1,232 @@ > +/* > + * bcb.c: Reboot hook to write bootloader commands to > + * the Android bootloader control block > + * > + * © Copyright 2012 Intel Corporation > + * Author: Andrew Boie <[email protected]> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; version 2 > + * of the License. > + */> + > +#include <linux/module.h> > +#include <linux/moduleparam.h> > +#include <linux/blkdev.h> > +#include <linux/reboot.h> > + > +#define BCB_MAGIC 0xFEEDFACE > + > +/* Persistent area written by Android recovery console and Linux bcb driver > + * reboot hook for communication with the bootloader. Bootloader must > + * gracefully handle this area being unitinitailzed */> +struct bootloader_message { > + /* Directive to the bootloader on what it needs to do next. > + * Possible values: > + * boot-NNN - Automatically boot into label NNN > + * bootonce-NNN - Automatically boot into label NNN, clearing this > + * field afterwards > + * anything else / garbage - Boot default label */> + char command[32]; > + > + /* Storage area for error codes when using the BCB to boot into special > + * boot targets, e.g. for baseband update. Not used here. */> + char status[32]; > + > + /* Area for recovery console to stash its command line arguments > + * in case it is reset and the cache command file is erased. > + * Not used here. */> + char recovery[1024]; > + > + /* Magic sentinel value written by the bootloader; don't update this > + * if not equalto to BCB_MAGIC */> + uint32_t magic; > +}; > + > +/* TODO: device names/partition numbers are unstable. Add support for looking > + * by GPT partition UUIDs */> +static char *bootdev = "sda"; > +module_param(bootdev, charp, S_IRUGO); > +MODULE_PARM_DESC(bootdev, "Block device for bootloader communication"); > + > +static int partno; > +module_param(partno, int, S_IRUGO); > +MODULE_PARM_DESC(partno, "Partition number for bootloader communication"); > + > +static int device_match(struct device *dev, void *data) > +{ > + if (strcmp(dev_name(dev), bootdev) == 0) > + return 1; > + return 0; > +} > + > +static struct block_device *get_emmc_bdev(void) > +{ > + struct block_device *bdev; > + struct device *disk_device; > + > + disk_device = class_find_device(&block_class, NULL, NULL, device_match); > + if (!disk_device) { > + pr_err("bcb: device %s not found!\n", bootdev); > + return NULL; > + } > + bdev = bdget_disk(dev_to_disk(disk_device), partno); > + if (!bdev) { > + dev_err(disk_device, "bcb: unable to get disk (%s,%d)\n", > + bootdev, partno); > + return NULL; > + } > + /* Note: this bdev ref will be freed after first > + bdev_get/bdev_put cycle */> + return bdev; > +} > + > +static u64 last_lba(struct block_device *bdev) > +{ > + if (!bdev || !bdev->bd_inode) > + return 0; > + return div_u64(bdev->bd_inode->i_size, > + bdev_logical_block_size(bdev)) - 1ULL; > +} > + > +static size_t read_lba(struct block_device *bdev, > + u64 lba, u8 *buffer, size_t count) > +{ > + size_t totalreadcount = 0; > + sector_t n = lba * (bdev_logical_block_size(bdev) / 512); > + > + if (!buffer || lba > last_lba(bdev)) > + return 0; > + > + while (count) { > + int copied = 512; > + Sector sect; > + unsigned char *data = read_dev_sector(bdev, n++, §); > + if (!data) > + break; > + if (copied > count) > + copied = count; > + memcpy(buffer, data, copied); > + put_dev_sector(sect); > + buffer += copied; > + totalreadcount += copied; > + count -= copied; > + } > + return totalreadcount; > +} > + > +static size_t write_lba(struct block_device *bdev, > + u64 lba, u8 *buffer, size_t count) > +{ > + size_t totalwritecount = 0; > + sector_t n = lba * (bdev_logical_block_size(bdev) / 512); > + > + if (!buffer || lba > last_lba(bdev)) > + return 0; > + > + while (count) { > + int copied = 512; > + Sector sect; > + unsigned char *data = read_dev_sector(bdev, n++, §); > + if (!data) > + break; > + if (copied > count) > + copied = count; > + memcpy(data, buffer, copied); > + set_page_dirty(sect.v); > + unlock_page(sect.v); > + put_dev_sector(sect); > + buffer += copied; > + totalwritecount += copied; > + count -= copied; > + } > + sync_blockdev(bdev); > + return totalwritecount; > +} > + > +static int bcb_reboot_notifier_call( > + struct notifier_block *notifier, > + unsigned long what, void *data) > +{ > + int ret = NOTIFY_DONE; > + char *cmd = (char *)data; > + struct block_device *bdev = NULL; > + struct bootloader_message *bcb = NULL; > + > + if (what != SYS_RESTART || !data) > + goto out; > + > + bdev = get_emmc_bdev(); > + if (!bdev) > + goto out; > + > + /* make sure the block device is open rw */> + if (blkdev_get(bdev, FMODE_READ | FMODE_WRITE, NULL) < 0) { > + pr_err("bcb: blk_dev_get failed!\n"); > + goto out; > + } > + > + bcb = kmalloc(sizeof(*bcb), GFP_KERNEL); > + if (!bcb) { > + pr_err("bcb: out of memory\n"); > + goto out; > + } > + > + if (read_lba(bdev, 0, (u8 *)bcb, sizeof(*bcb)) != sizeof(*bcb)) { > + pr_err("bcb: couldn't read bootloader control block\n"); > + goto out; > + } > + > + if (bcb->magic != BCB_MAGIC) { > + pr_err("bcb: bootloader control block corrupted, not writing\n"); > + goto out; > + } > + > + /* When the bootloader reads this area, it will null-terminate it > + * and check if it matches any existing boot labels */> + snprintf(bcb->command, sizeof(bcb->command), "bootonce-%s", cmd); > + > + if (write_lba(bdev, 0, (u8 *)bcb, sizeof(*bcb)) != sizeof(*bcb)) { > + pr_err("bcb: couldn't write bootloader control block\n"); > + goto out; > + } > + > + ret = NOTIFY_OK; > +out: > + kfree(bcb); > + if (bdev) > + blkdev_put(bdev, FMODE_READ | FMODE_WRITE); > + > + return ret; > +} > + > +static struct notifier_block bcb_reboot_notifier = { > + .notifier_call = bcb_reboot_notifier_call, > +}; > + > +static int __init bcb_init(void) > +{ > + if (partno < 1) { > + pr_err("bcb: partition number not specified\n"); > + return -1; > + } > + if (register_reboot_notifier(&bcb_reboot_notifier)) { > + pr_err("bcb: unable to register reboot notifier\n"); > + return -1; > + } > + pr_info("bcb: writing commands to (%s,%d)\n", > + bootdev, partno); > + return 0; > +} > +module_init(bcb_init); > + > +static void __exit bcb_exit(void) > +{ > + unregister_reboot_notifier(&bcb_reboot_notifier); > +} > +module_exit(bcb_exit); > + > +MODULE_AUTHOR("Andrew Boie <[email protected]>"); > +MODULE_DESCRIPTION("bootloader communication module"); > +MODULE_LICENSE("GPL v2"); Andrew Boie - June 29, 2012, 9:56 p.m. > From: NeilBrown [mailto:[email protected]] > Sent: Friday, June 29, 2012 2:25 PM > > On Fri, 29 Jun 2012 12:36:30 -0700 Andrew Boie <[email protected]> > wrote: > > > Android userspace tells the kernel that it wants to boot into recovery > > or some other non-default OS environment by passing a string argument > > to reboot(). It is left to the OEM to hook this up to their specific > > bootloader. > Maybe I'm missing something obvious, but why does this need to be > implemented > in the kernel? Can't some user-space process just write to that partition > using open/read/seek/write/close before calling 'reboot'. Thanks for reviewing. The way Android is currently designed, all calls to reboot the system into an alternate target go into android_reboot() in libcutils which then make the reboot() system call with a string argument. How this is actually done on a particular board is not specified in the Android Open Source Project as far as I can see. The particular bootloader is not specified either, many different ones are being used in practice. Not every architecture is going to be using the Bootloader Control Block to handle these boots into alternate targets. For example, I worked on one Android-based device that didn't have a traditional bootloader at all and the reboot hook in the kernel was radically different. In this case the BCB ended up only being used by the recovery console to stash its command line arguments. If this were all done in userspace, then I think there would have to be separate code paths in libcutils for different board implementations of this policy. As of right now libcutils doesn't have any hardware-specific stuff in it and the mechanism to effect these policies is left to the kernel, libcutils works everywhere without modification. Regards, Andrew --To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ [email protected] - June 30, 2012, 3:08 a.m. On Fri, Jun 29, 2012 at 09:56:36PM +0000, Boie, Andrew P wrote: > > From: NeilBrown [mailto:[email protected]] > > Sent: Friday, June 29, 2012 2:25 PM > > > > On Fri, 29 Jun 2012 12:36:30 -0700 Andrew Boie <[email protected]> > > wrote: > > > > > Android userspace tells the kernel that it wants to boot into recovery > > > or some other non-default OS environment by passing a string argument > > > to reboot(). It is left to the OEM to hook this up to their specific > > > bootloader. > > > Maybe I'm missing something obvious, but why does this need to be > > implemented > > in the kernel? Can't some user-space process just write to that partition > > using open/read/seek/write/close before calling 'reboot'. > > Thanks for reviewing. The way Android is currently designed, all calls > to reboot the system into an alternate target go into android_reboot() > in libcutils which then make the reboot() system call with a string > argument. How this is actually done on a particular board is not > specified in the Android Open Source Project as far as I can see. The > particular bootloader is not specified either, many different ones are > being used in practice. Which is fine, the kernel doesn't, and shouldn't care about this. > Not every architecture is going to be using the Bootloader Control > Block to handle these boots into alternate targets. For example, I > worked on one Android-based device that didn't have a traditional > bootloader at all and the reboot hook in the kernel was radically > different. In this case the BCB ended up only being used by the > recovery console to stash its command line arguments. So what architectures are going to be using this? > If this were all done in userspace, then I think there would have to > be separate code paths in libcutils for different board > implementations of this policy. As of right now libcutils doesn't have > any hardware-specific stuff in it and the mechanism to effect these > policies is left to the kernel, libcutils works everywhere without > modification. So, without that, the kernel is setting the policy here instead? That's generally the opposite of what we want to do, it's up to userspace to determine things like this. confused, greg k-h --To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ [email protected] - June 30, 2012, 3:23 a.m. On Fri, Jun 29, 2012 at 12:36:30PM -0700, Andrew Bo
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 More in the link provided above
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 Whr all gone ??? They have locked the bootloader with some key
Guest Posted August 5, 2012 Report Posted August 5, 2012 Whr all gone ??? They have locked the bootloader with some key The question is, can we get that key ?
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 We have 5-6 emails id in above link :-D we can get that key... or we have to guess that key which is almost impossible
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 Ics was ready on 1st may ....they are spending months in patching
Guest kabirsaini2011 Posted August 5, 2012 Report Posted August 5, 2012 The bootloader will always populate a magic signature in the BCB; the driver will refuse to update it if not present
Guest Posted August 5, 2012 Report Posted August 5, 2012 Ics was ready 1st may, well we all know what patching they are doing, screwing up things for us. I have never heard of this kind of anit-android stuff. They go completely against the open source nature of android. Lock bootloader, fair enough, but to go to ends of earth to ensure no hack will work, seems like a personal attack on android.lol
Guest vermat17 Posted August 5, 2012 Report Posted August 5, 2012 That was one point I really stressed when I ranted at them :P Hopefully they'll take some notice of us... :/
Guest brit07 Posted August 5, 2012 Report Posted August 5, 2012 This driver uses the bootloader control block (BCB) in the 'misc' partition, which is the AOSP mechanism used to communicate with the bootloader. Writing 'bootonce-NNN' to the command field will cause the bootloader to do a oneshot boot into an alternate boot label NNN if it exists. The device and partition number are passed in via kernel command line.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now