[KERNEL] (Patch) USB OTG (host mode) + simultaneous charging! - Xperia Z5 Compact Android Development
(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)
I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.
Acknowledgements:
HUGE thanks...
...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
...and to @Phoenix Wright for further refining that code
The patches presented here are based largely off of Phoenix Wright's work.
Background:
I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.
I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.
Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.
Use:
Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.
This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.
This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.
Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.
Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).
'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.
Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.
If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.
Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.
In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:
dwc3_msm.force_float_on_bsv=N
(disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
qpnp_smbcharger_extension.force_id_polling_on=Y
(disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
dwc3.no_device_timeout_enable=N
(disables host mode timeout in the event controller does not detect a device)
dwc3.aca_enable=Y
(enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
dwc3.prop_chg_aca_enable=Y
(additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)
I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.
-- Nathan
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there: https://forum.xda-developers.com/showpost.php?p=64784909&postcount=8403 (I think there was an issue with kernel panics in certain circumstances which was fixed by a msleep(), maybe something else too).
Phoenix Wright said:
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:
Click to expand...
Click to collapse
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
nlra said:
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
Click to expand...
Click to collapse
A lot of time has passed, but if I'm not mistaken, on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Phoenix Wright said:
[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Click to expand...
Click to collapse
Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)
Nevertheless, I ran some tests:
1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.
2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.
3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).
So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".
Thanks again,
-- Nathan
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
tarsonis666 said:
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
Click to expand...
Click to collapse
You are correct, this file is used to patch the kernel (not the ROM) source and then compile the kernel binaries.
Files you flash in TWRP usually end in ".zip" or ".img".
// DevelLevel
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Adamell0 said:
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Click to expand...
Click to collapse
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
nlra said:
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
Click to expand...
Click to collapse
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Adamell0 said:
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Click to expand...
Click to collapse
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
nlra said:
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
Click to expand...
Click to collapse
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Adamell0 said:
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Click to expand...
Click to collapse
I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)
The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.
Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.
If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.
Link to TA backup utility: https://forum.xda-developers.com/t/universal-dirtycow-based-ta-backup-v2.3514236/
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
nlra said:
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
Click to expand...
Click to collapse
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Adamell0 said:
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Click to expand...
Click to collapse
Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.
Your kernel is also ready, tested, and attached.
Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.
Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.
Related
Nexus 7 Bits and Pieces
I thought I would put all of my findings in one thread, feel free to ask questions below.
Dock Connector
The dock connector is functional in the latest branch of the Nexus 7 kernel found on android source (android-tegra3-grouper-3.1-jb-mr1-fr). The top pin is ground, the second is the right audio channel, the third the left and the bottom pin is 5V. Upon connecting the ground and 5V lines the audio on the dock connector is enabled and the internal speaker is disabled. I used a piezo element to check so I'm not sure how good the audio is, but it is definately there.
Variants
From the kernel source code there are 3 different project ids but 4 names. Nakasi (the standard Nexus 7), Nakasi 3G, Bach and ME370TG. Nakasi 3G and Bach share the same project ID. This is interesting as the project id table states that Nakasi and ME370T are the same, but also separates the ME370TG and Nakasi 3G. It is also revealed that there are, or have been, two power management ICs and two GPS ICs used in the product. For power management both a TI chip and a Maxim chip have been used, though I believe all? of the current Nexus 7 have the Maxim one. The two GPS' used have been the BCM47511 and BCM4751. In addition to this there have been 4/6 PCB revisions. SR3 appears to be very early as some of the code excludes it, and it also has ID 0 assigned. ER1-ER3 appear to be the current series and my C9O Nexus 7 is revision 3, this can be checked in the bootloader, it is noted as "HW VERSION" or version-hardware in fastboot ("fastboot getvar all").
In my kernel compile below I have added a simple debug output that displays the PMIC ID, project ID and pcb ID. If you decide to test the below kernel for the dock functionality it'd be appreciated if you post the output from /proc/kmsg. The line that I have added looks something like "HEADSET: PMIC: 0 Project ID: 0 Revision: 3 UART_enable:1". This means that I have the Maxim PMIC, it's a Nakasi device and the PCB is revision ER3. The reason it's in headset is explained below.
Fastboot OEM Commands
The oem lock and oem unlock commands are well known, however through looking at the bootloader run through strings I have found 4 additional commands that may be of use. I have found oem off-mode-charge 0 and oem off-mode-charge 1. These appear to enable or disable off mode charging, eg charging without the device being on. The more interesting command is however oem uart-on (and oem uart-off). This causes the bootloader to pass debug_uartport=lsport,0 to the kernel, I am not sure however where "lsport" is but it is referenced in arch/arm/mach-tegra/common.c, if uart is not enabled in the bootloader (evident by fastboot getvar all showing uart-on as no) then the bootloader passes debug_uartport=hsport. The 0 appears to indicate the port it outputs on.
Headset UART Output
In the headset driver (/sound/soc/tegra/headset.c) there is reference to a debug board that can be used to get a UART output. From what I understand this is enabled by setting a line-out pin low, however I am having issues working out which one. I have also attempted to enable this for anything inserted, and while this worked, my simple 4 connector 3.5mm plug breakout didn't reveal any data. I'm leaving this one out there for other people to try. For reference, https://android.googlesource.com/kernel/tegra/+/b0d6be9e2033745e46624e518f55e067b75bcd50 is the commit when the debug board was added. I also commented out it's PMIC check to ensure that it did not stop because I have a Maxim PMIC. This should not matter I believe it is just a way to filter out retail Nexus 7s as it can supposedly cause issues with powered headphones.
The driver also shows the possibility for headset support, however I have yet to investigate this.
Kernel Build
I have built a kernel in an attempt to enable as much of the above as is possible. It has working dock functionality and some additional debug information in relation to the headset UART output. My only changes from the default branch are in headset.c and are as follows:
Code:
if(project_info == GROUPER_PROJECT_BACH ||
(project_info == GROUPER_PROJECT_NAKASI/* && pmic_id ==GROUPER_PMIC_TI*/))
UART_enable = true;
revision = grouper_query_pcba_revision();
printk("HEADSET: PMIC: %i Project ID: %i Revision: %i UART_enable: %i\n", pmic_id, project_info, revision, UART_enable);
It should be fairly obvious what bit of code it replaces, it's in headset_init(void).
I have only provided the kernel as a ramdisk and zImage as the ramdisk depends upon the ROM you use. If you use CM10 then these will work, else you'll have to extract the ramdisk from your current boot.img with a tool such as abootimg. This can be run using the fastboot boot command, "fastboot boot zImage initrd.img" or by using the fastboot flash:raw command, "fastboot flash:raw boot zImage initrd.img". The latter is permanent while the former is once only.
This kernel does not support overclocking, special IO schedulers or any special "optimizations". It never will, it is purely to work out how to activate some of the hidden functions in our Nexus 7s.
Note to Moderators
Wasn't really sure where this thread should go, if you feel this should be moved then please do.
Update Update to the status of UART. I have successfully got it recognizing the headphone port as a debug board, however I cannot yet get any output. To make it see a debug board, ensure that you have a 4 piece connector (yes the Nexus 7 hardware supports a headset) and connect ground to band 3 (band 1 being the tip) and 3.3v to band 4. When you plug it in it'll be reported as debug board if using my kernel.
So to make a speaker dock, is it really just as basic as hooking up the right speaker to the right pogo pin for sound to start playing?
That and 5V to the respective pins. You will also need a kernel based on the newer android-tegra3-grouper-3.1-jb-mr1-fr branch. The kernel I posted above will work.
ben1066 said: That and 5V to the respective pins. You will also need a kernel based on the newer android-tegra3-grouper-3.1-jb-mr1-fr branch. The kernel I posted above will work. Click to expand... Click to collapse Right. Of course. It is just that I remember when someone was reverse engineering the galaxy nexus dock I believe the dock had like a motherboard and chip that needed to be decoded for the dock (and everything else) to work properly. But this is so simple! Maybe I will take the plunge with this one to try and build myself.
Not so here, it works straight off the bat. Also got the ME370T schematic and it appears I'm connecting to the UART right, I think maybe the kernel is doing something wrong, or I've killed the port on my Nexus 7 with a massive 3.3V, that seems unlikely as I was also using 3.3V to make it detect it as a debug board.
ben1066 said: Also got the ME370T schematic Click to expand... Click to collapse Omg please share
Google is your friend, it's not that hard to find. I shouldn't really post a direct link.
ben1066 said: Google is your friend, it's not that hard to find. I shouldn't really post a direct link. Click to expand... Click to collapse Do you mean the one on baidu? I was hoping for one that has the full 90 pages
I only have the 44 page one unfortunately, however it does contain the UART specific bit. I'm now wondering if the odm_production_mode fuse disables it. I don't suppose if anyone still has an ICS Nexus 7 and if they could get me in touch with them?
Coming soon to a Nexus 7 near you.
jonnyg1097 said: So to make a speaker dock, is it really just as basic as hooking up the right speaker to the right pogo pin for sound to start playing? Click to expand... Click to collapse I'm going to assume that this will be a line level signal. You will need a preamp/amplifier to power your speaker.
Mr. Thompsn said: I'm going to assume that this will be a line level signal. You will need a preamp/amplifier to power your speaker. Click to expand... Click to collapse I see, I am no sound expert so I got a question to ask... if I dont have one of those attached to it will sound still come out but just not clearly or not come out at all? Or what if I were to use put one in and it's not needed would it affect it in any way?
You will need amplification to get any reasonable volume above that for headphones.
Can we charge the N7 through those +5v and ground pins? Possible touchstone charger case mod?
We can charge however the kernel will need modifying to ignore it when it comes down to audio, otherwise you will end up having no audio out while it's charging, at least through the speaker. Headphone port overrides the dock.
Asus dock I had wondered what those pins were for when I unboxed my N7. Isn't Asus supposed to be coming out with a dock for this thing? I saw a picture of it a week or two ago and I really want it.
Not to sound pessimistic, but I think the Nexus 7 II will be shipping before anyone gets around to making a pogo dock... Sent from my Nexus 7 using Tapatalk 2
ben1066 said: We can charge however the kernel will need modifying to ignore it when it comes down to audio, otherwise you will end up having no audio out while it's charging, at least through the speaker. Headphone port overrides the dock. Click to expand... Click to collapse I'm not really interested in the sound part. The only thing I miss from my HP Touchpad is the inductive charging. These pogo pins seem like the easiest way to add inductive charging to my N7. Sent from my Nexus 7 using Tapatalk 2
ben1066 said: That and 5V to the respective pins. You will also need a kernel based on the newer android-tegra3-grouper-3.1-jb-mr1-fr branch. The kernel I posted above will work. Click to expand... Click to collapse so clarify this for me. There is only single channel audio from the pogo dock port?
N7100, charge while in USB host mode.
Hello. I'm aware that it is possible to get an N7100 to charge while in USB host mode via a h/w mod. I was wondering if the same thing were possible via a kernel modification? Has anyone got any idea where I need to look? I found an answer to this question for a different phone: "On the*Galaxy*Nexus, removing the complete body of method tuna_set_vbus_drive() in arch/arm/mach-omap2/board-tuna-connector.c will disable charging of OTG slave devices and will allow the OTG host itself to be charged. The battery icon will not be updated by this modification alone." This particular file doesn't exist on the N7100 + Omni (or i haven't it), so i guess the functionality must be somewhere else. Thanks.
kaleb500 said: Hello. I'm aware that it is possible to get an N7100 to charge while in USB host mode via a h/w mod. I was wondering if the same thing were possible via a kernel modification? Has anyone got any idea where I need to look? I found an answer to this question for a different phone: "On the*Galaxy*Nexus, removing the complete body of method tuna_set_vbus_drive() in arch/arm/mach-omap2/board-tuna-connector.c will disable charging of OTG slave devices and will allow the OTG host itself to be charged. The battery icon will not be updated by this modification alone." This particular file doesn't exist on the N7100 + Omni (or i haven't it), so i guess the functionality must be somewhere else. Thanks. Click to expand... Click to collapse With the 4210s, the USB interface chip WAS capable of detecting a USB ACA (Accessory Charger Adapter). CM and derivatives supported ACAs on the 4210 devices thanks to a patch. I'm not sure if the Exynos 4412 USB interface chip (Samsung used the same chip on all 4412-based devices to my knowledge, except for maybe the N80xx family) has the same capability. Unfortunately, many of the Y-adapters out there aren't proper ACAs. I'd be willing to support proper ACAs IF they can be detected correctly, but I'm not going to allow any workaround hacks that don't follow the USB standards.
[Kernel] [Development] Linux-next for the Ouya Console, Release Alpha 0.10
This is the first release of the Linux-next kernel for the Ouya. **** DANGER! DRAGONS AHEAD! **** This has been tested on one device only (mine). It may cause your device to melt or become sentient. I hold no warranty or liability should you decide to use this! It supports the Kickstarter Edition Ouya only. It may work on the newer variant of the Ouya, but I don't have one. I need information from a newer variant to determine how to support it. I have tested the video on a HP monitor DVI, a Samsung TV HDMI, and a Xbox One HDMI in. The HP monitor and Xbox One work, but at 1080p there is display corruption, everything was fine at 720p. The Samsung TV causes it to hard lock immediately. I suggest using xfce4 with lightdm, as they are lightweight enough that they run without issue. I use the Ouya Safeboot Menu for this, and it works well. The Buildroot will attach to eth0 DHCP and spin up a SSH server. User: root Password: ouyaouya If you use this, I ask the following: Boot only using fastboot boot or Ouya Safeboot Menu, if you flash it to the boot partition, that's on you! You cannot flash the buildroot, it is too big, so don't even try. Boot it the first time with HDMI unplugged. SSH in, then run the 'dmesg -w" command. Plug HDMI in. Copy the entire boot log and send it to me. The following changes were made to the source code: Trusted Foundations support for the L2 cache controller. Cpufreq support for the T30 series. (This has been merged into the T20 driver in mainline. GPT sector forced searching for eMMC support. The following limitations are known: Kernel is unstable, it has been known to panic. eMMC may be unstable, I'm running it slightly hotter than original, but within spec, let me know if you have issues. Bluetooth is enabled, but loads with a random MAC address, it will pair, but I haven't gotten services to play nice yet. Audio is enabled, but I haven't gotten it working yet. Video support is hit or miss, and there is very little graphics acceleration. Ethernet chip loads with a random MAC address. There is no power management to speak of. Power off does not work, but reboot does. The following does work: Wifi (Need the OUYA firmware binaries, the open source ones do not work) eMMC Cpufreq RTC USB Ethernet Video (With Caveats) Frequently Asked Questions: How do I get video to work? Video requires use of the Grate-Driver, https://github.com/grate-driver. Changelog: None yet. Source: https://github.com/pgwipeout/linux/tree/Linux-Next-Ouya-Alpha-0.10 Buildroot Image: https://drive.google.com/file/d/1M1ed4wWIqQQzfVqGUsR8i946Gztr1KdK/view?usp=sharing Kernel Only Image: https://drive.google.com/file/d/1xiowFwVDou4LssyfObzjaxHAy7ecc3Fh/view?usp=sharing XDA:DevDB Information Ouya Linux-Next, Kernel for the Ouya Contributors pgwipeout, Dmitry Osipenko, Matt Merhar Source Code: https://github.com/pgwipeout/linux/tree/Linux-Next-Ouya-Alpha-0.10 Kernel Special Features: Version Information Status: Alpha Created 2018-05-31 Last Updated 2018-05-31
Reserved for later use.
Reserve for future use.
Very nice. Keep it up. Let's revive Ouya
I cannot believe that someone working on something for Ouya. If you'll need help with testing contact me
Just got an Ouya for $17 shipped. Works great, but would love to update it.
Hi, I just wanted to see if you had any updates on this. I would love to run this on my Ouya, to use it as a small home server. Thank you!
[ROOT] Rooting the FireTV Cube and Pendant with FireFU
Today we’re excited to be bringing you something we’ve been working on for the last few months. Today, we’re introducing you to FireFU. FireFU is an exploit chain we’ve created to allow users to unlock (and root) their FireTV Cube and FireTV Pendant.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
https://blog.exploitee.rs/2018/rooting-the-firetv-cube-and-pendant-with-firefu/
Exploit package
This download is intended for users who are only seeking the binaries to perform the exploit.
https://download.exploitee.rs/file/amazon/FireFU/FireFU.tgz
Source Code
This is for the users who are needing to recompile the exploit or are just curious about the process.
https://gitlab.com/Exploiteers/FireFU_Exploit
https://gitlab.com/Exploiteers/amlogic_usb_mmc
This is nowhere near achievable for most XDA users though.
This is amazing. Thanks a lot. I'm completely newbie but look forward testing this. Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately? EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore. Regards and congratulations. Pino.
puppinoo said: This is amazing. Thanks a lot. I'm completely newbie but look forward testing this. Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately? EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore. Regards and congratulations. Pino. Click to expand... Click to collapse Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications.
xXhighpowerXx said: Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications. Click to expand... Click to collapse Thanks for precious info, I already blocked URLs from Amazon on my LEDE router in dnsmasq.conf. Really interesting. I have LibreElec installed on my Odroid C2 and the idea of installing a Linux distro on the pendant is also interesting. BTW I stress my gratitude cause your work is amazing. Pino.
xXhighpowerXx said: . Click to expand... Click to collapse Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project? https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct? Also, would it be possible to provide a little more detail on the command line steps needed? I'm a Linux novice so I'm having a little difficulty trying to figure out how to execute some of these steps. The exact commands for each step would be great. Thanks for your work!
AZImmortal said: Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project? https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct? Click to expand... Click to collapse Correct. Something like this is what you need. This looks like the one used in the wiki. IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout. (The Linux rooting commands are in the video.)
retyre said: Correct. Something like this is what you need. This looks like the one used in the wiki. IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout. (The Linux rooting commands are in the video.) Click to expand... Click to collapse Thanks for confirming about the HDMI breakout. I found this on AliExpress for the cheapest option (but longest delivery time). Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines). Also, I saw the video but it seems to start at step 7, which is basically where the easy parts of the process start, haha. I need more details on the earlier steps.
AZImmortal said: Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines). Click to expand... Click to collapse There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ... Take a look at something like this if you want to automate the last part (udev).
retyre said: There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ... Click to expand... Click to collapse I have an Arduino clone but I've never actually used it for real (other than flashing sketches to it to make sure that it works), but assuming that the clone is functional, then what kind of issues might prevent it from working for this project? I guess same question goes for the breakout board and USB 3.0 vs 2.0. Just trying to figure out what kind of obstacles I might encounter if I decide to try this. retyre said: Take a look at something like this if you want to automate the last part (udev). Click to expand... Click to collapse This helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though. Thanks for the help so far.
AZImmortal said: his helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though. Click to expand... Click to collapse Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check. Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly. Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear. There's only one way to find out. Gather the paraphernalia, test it out, and post here!
retyre said: Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check. Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly. Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear. There's only one way to find out. Gather the paraphernalia, test it out, and post here! Click to expand... Click to collapse Thanks, this helps a lot. I'll have to take a little time to experiment with my setup to see if I can figure out the syntax, but I'm definitely planning to buy the breakout board and finally put my Arduino clone to work. I'll probably have more questions when that time comes.
Finally got around to trying this. Works as described in the OP. TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.
retyre said: Finally got around to trying this. Works as described in the OP. TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues. Click to expand... Click to collapse Great job. Waiting for my hdmi breakout to arrive so I can try. Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks. Regards. Pino.
puppinoo said: Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks. Click to expand... Click to collapse I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?
retyre said: I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image? Click to expand... Click to collapse Glad it worked for you. Any chance you could show links to the board and Hdmi breakout? Thank you. ---------- Post added at 06:00 AM ---------- Previous post was at 05:56 AM ---------- Nevermind I found them in the Wiki.
retyre said: Finally got around to trying this. Works as described in the OP. TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues. Click to expand... Click to collapse I plan on trying this tonight. It's not clear in the instructions how to connect everything. Connect the arduino to a linux box via USB? Do I need to adb to enter the commands? I've got the breakout HDMI wired to the arduino, but then a standard HDMI cable from breakout to FireTV?
Let me clarify the first few steps in the OP (this is where I expect most of the challenge to be):
-- This is what you will need to begin: Arduino Due (this is what I have), HDMI breakout board (this is what I used because I have the pendant; if you have the cube, you will need a male HDMI as in the wiki; if you have the pendant, you can also use the male with a coupler), M/M jumper wire (this is what I used), and a Linux box (I have Ubuntu 16.04.5 LTS installed).
To install the Arduino IDE and upload the sketch, follow these steps in sequence:
1. Download the Arduino IDE. (If you use v1.6.1 or earlier, you don't have to install the Due board separately.) For Linux, download v1.6.1 from here. (Note: You don't have to do this in Linux. For Windows, use this.)
General note for Linux: It might just be easier to run everything as root (to sidestep permission issues): use sudo. As an example, sudo ./arduino to start the Arduino IDE instead of just ./arduino.
2. Connect the Due to your PC's USB port, install the Windows driver (located inside arduino-1.6.1-windows.zip; no driver needed for Linux), and choose the correct Board (Native or Programming depending on which is connected; I usually use the Programming port) and Port.
3. Download and extract the archive in the OP (FireFU.tgz).
4. Upload the sketch (hdmi_arduino.ino, from the archive) to the Due. To do this, open hdmi_arduino.ino from File and choose Upload from Sketch or just click the right-arrow. Pull up the separator at the bottom to make it easier to view the progress window.
6. Confirm that the upload and verification are successful.
You will need Linux from this point forward.
5. Check to see whether libusb is already installed:
Code:
dpkg -l libusb*
If not, install it:
Code:
sudo apt-get install libusb-1.0-0
6. Add the proper udev rules for Amlogic and fastboot as described in the OP's link. If you do not know how to manually add rules in /etc/udev/rules.d/, do the following:
-- To automate the udev rule for Amlogic (from here):
Code:
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
This will write the Amlogic rule (/etc/udev/rules.d/70-*). To add the fastboot rule, open the file (70-*) in an editor, copy-and-paste the line for Amlogic, and change the vendor and product id to match that for fastboot.
To manually add the udev rules, create a new file (say, 70-firetv3.rules) with the following in it:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1b8e", ATTR{idProduct}=="c003", MODE:="0666"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="18d1", ATTR{idProduct}=="0d02", MODE:="0666"
-- Install fastboot and adb:
Code:
sudo apt-get install android-tools-adb android-tools-fastboot
7. Reboot for the rules to take effect.
8. Connect the following in order:
-- jumper wire to SCL, SDA, and GND on the Due ... and to the breakout board (as described in the wiki)
-- AFTV3's male HDMI to the breakout board's female HDMI (or the cube's female HDMI to the breakout board's male HDMI)
-- power to the Due (I use external power, but connecting it to USB power should work just as well)
-- micro USB to the AFTV3
-- other end of the micro USB to the Linux box's USB port
9. Check whether Amlogic, Inc. shows up:
Code:
lsusb
10. If it does, you're more than halfway there. If it does not, disconnect everything but the jumper wire and repeat step 8.
retyre said: I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image? Click to expand... Click to collapse Thanks for advices. I didn't know updates URLs were still unknown. I just enabled updates and let it do its things. Now I'm on Build NS6255/1612 (hoping it's the original one and not some stealth tricky version just uploaded ). BTW I noticed the updates are incremental so it processed all the major ones one at a time. So maybe you could let it do until it reaches the version you like and after that you stop the updates. It's not a safe method I think (for them). BTW Thanks again for advice. Stuill waiting for HDMI Breakout.
Arduino Documentation retyre said: -- power to the Due (I use external power, but connecting it to USB power should work just as well) Click to expand... Click to collapse Documentation on the Arduino website states; "The Arduino Due can be powered via the USB connector or with an external power supply. The power source is selected automatically. External (non-USB) power can come either from an AC-to-DC adapter (wall-wart) or battery. The adapter can be connected by plugging a 2.1mm center-positive plug into the board's power jack. Leads from a battery can be inserted in the Gnd and Vin pin headers of the POWER connector. The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable. If using more than 12V, the voltage regulator may overheat and damage the board. The recommended range is 7 to 12 volts"
[Q] Is it possible to mirror Sony Xperia XZ1 / XZ1 Compact screen using USB-C adapter
Is it possible to mirror Sony Xperia XZ1 / XZ1 Compact screen using USB-C adpater? I'm not responsible if your device may become unusable or if you buy wrong adapter, I'm writing here to ask people and if I discover something amazing, to share it. Read carefully and help together Click to expand... Click to collapse Is there any possibility to connect our device to USB-C adapter dedicated for e.g. chromebooks? I found something like that on Reddit: https://www.reddit.com/r/SonyXperia/comments/8jxmmq/hdmi_support_on_xperia_xz1/ It is questionable issue... Because of that: "Although the Xperia XZ1 Compact’s Snapdragon 835 processor is technically capable of allowing DisplayPort Alt Mode over USB-C, for some reason Sony have opted not to include this functionality" So the question is, if we install custom rom instead of stock firmware, maybe it will work? There may not be any restrictions. Information About processor I mentioned, I found here: https://www.mobilefun.co.uk/blog/2017/12/how-to-connect-xperia-xz1-compact-to-your-tv/ https://www.qualcomm.com/documents/snapdragon-835-mobile-platform-product-brief Also I found SIMPLE adapter: https://www.amazon.com/Multiport-Co...rds=3+in+1+hdmi+adapter&qid=1574113813&sr=8-9 Did anyone try something like that, is there any required applications like that mentioned on reddit? NOW I'M ON LineageOS 16 customROM: For now I'm on LineageOS 16 on both devices. I have plan to flash LineageOS 17 if there will be working Viper4android and edxposed on both devices. How android 10 may work with it? As we know, in android 10 there is desktop mode! Is it included in LineageOS 17? But why we have to use only USB C ==> HDMI adapter? I was searching for station with much more features. I saw something with Ethernet, card reader, USB, mini jack and hdmi in one - https://www.amazon.com/i-tec-USB-C-...ds=I-TEC+USB-C+station&qid=1575216994&sr=8-16 - https://www.amazon.com/gp/aw/d/B0816D3BW6/ref=sspa_mw_detail_3?ie=UTF8&psc=1 Please share here your discoveries. Leave here pictures links for videos with tests and anything which may help. I'm not specialist but just interested person and one more Xperia owner Click to expand... Click to collapse
"Changelog" 17.03.2020 1. Title change 2. Some other improvements 22.02.2020 1. Change customRom to LineageOS 16 2. Change Title 12.02.2020 1. Add XZ1 in title instead of only XZ1C (because of that they are similar in construction) from now if I buy adapter I'll have possibility to test XZ1 either. I mostly care about XZ1C and XZ1 is on second place 2. Add have plan for changing system 3. Minor fixes 4. Add please share your discoveries... 5. Add question about android 10 6. Add system switching information. 11.02.2020 1. Found second information about processors on qualcom website and add link. 2. Found adapter with one more features that previous advanced (that one with vga) and add link XX.XX.2019 Found new adapter with more features that may work with our device
I guess we need someone who can find and edit entries in the kernel for DP alt Mode.
I tried this Magisk module but it didn't work for me on Havoc OS 3.7. https://github.com/Magisk-Modules-Repo/edm
We can't even use USB3 speeds. To me that implies that they didn't even connect all the pins, namely the high speed ones that would be required for DP are not connected.
When I first got the XZ1 Compact it annoyed me there didn't appear to be any wired display options. I like to know I can do things even if it's unlikely I'll ever actually need to. So I bought the smallest DisplayLink adapter I could find and a power delivery USB C hub. Between the two I can output display and audio while simultaneously charging the phone. Number of times I've used this for anything meaningful, 0.
Vysor can do that. So can Anydesk