The kernel panic seems to be related to the driver trying to allocate
too many pages from the IO mapper. That may be caused by the fact
that we try to perform a 100+ MiB transfer in a single IO operation.
This change breaks the transfer down into 1 MiB chunks.
So far after a day of testing, no kernel panics have occurred compared
to 5 in the previous 24 hours!
Change-Id: I8d27a546e0c0bf4fe2f0fc7fcad65a88d3e6bee0
When using fastboot in scripts, it currently is necessary to parse the
output for FAILED messages and possible other indications of
error. This happens relatively often, for example when there are radio
update issues. Fortunately, fb_execute_queue already has a notion that
an error has occured which is used to abort the queue execution.
This change makes the status value be returned from fb_execute_queue
to main which can then return it as an exit status. usage cases were
also changed to return 1.
Note the code already returned 1 for error in one other case when
there was a problem with boot, so there is a precedent for return 1 on
error in this program.
Change-Id: Ib0463b08c8f2569495e248dd84e331f7e3691039
Merge commit 'ef063fe3066153dab5389b6baba6cb4e36888106'
* commit 'ef063fe3066153dab5389b6baba6cb4e36888106':
Add support for Acer devices
FreeBSD support for usb-connected devices in adb
Make get_my_path() safer
Fix use of memset function
Without this patch, "adb devices" will say "no permissions" when it sees
a device it can't write to, but "fastboot devices" will silently ignore it.
This is confusing to n00bs, especially since it doesn't seem to be widely
known that a device's USB id might be different in the bootloader (meaning
two udev rules are needed). It can also be confusing if you're sshed in,
when you can't access the device because you won't be in the "plugdev"
group, but "fastboot devices" won't make this clear.
I'm not sure about the Mac OS and Windows changes. AIUI, devices are always
writable on those platforms, but I don't use either, so I can't test this.
This patch shouldn't alter the behavior on either of those platforms.
If the USB connection to the device is reset but is still there
the code should retry to re-connect the device and continue.
This is a short term fix for a bootloader issue.
We should revisit and look for a better solution.
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
Add the --base flag to mkbootimg and -b flag to fastboot, to allow
the default kernel base address (0x10000000) to be changed.
Signed-off-by: Brian Swetland <swetland@google.com>
