Hi,
I wrote a patch to make the Moto G recognize the buttons of headsets/headphones. The hardware is capable of detecting the buttons, Motorola simply didn't write the code for it because at the time Android was not able to make use of them.
I have a minor problem that I can't easily overcome without help.
The chip that takes care of the detection simply reports some value when a button is pressed and this value depends on the specific headset used. It's up to the kernel decide what to do with that value. Each headset implements the buttons in a different way, so I need to gather some data. I think there's some sort of standard in the industry, so probably it will be possible to implement a generic solution (how can other devices do that otherwise?).
At the following address, you can find a simple patch that makes the kernel print that value whenever a button is pressed. It really does nothing other than that.
Code:
https://pastebin.com/raw.php?i=h9dnhmKr
To get the data I need, run from Terminal Emulator/adb the following (as root):
Code:
cat /proc/kmsg | grep TPA
(the command must be stopped manually: close Terminal Emulator/Ctrl+C/Vol down+C etc...)
Now, every time you press a button, you should see a new line (maybe more), for instance:
Code:
<6>[ 97.148228,0] TPA: value: 67
I'm interested in those values and their corresponding button, i.e. the button you pressed to get the line.
The value is not constant, you'll get different values for the same button. It's not a problem.
EDIT: I forgot to mention that the prebuilt kernel here below is for falcon. If you are using CM made for falcon, then this image is OK.
At the following address you can find a prebuilt kernel image made for the current CyanogenMod 12.1, anything not too distant from the currently nightly should be fine (I built the kernel three days ago) (do whatever you want with this prebuilt image, mirror it, repackages it etc...):
Code:
https://mega.nz/#!7A4SjQqZ!DPzO18k56e9364PciH7RC6rVCbrkuuUyqAcX9eFyd4I
Sources:
Code:
https://github.com/CyanogenMod/android_kernel_motorola_msm8226/ at acfe66c6fee + patch linked here above
If you want to test the prebuilt kernel image without flashing it, use fastboot:
Code:
fastboot boot path/to/the/boot.img
In this way, all you need to go back to your kernel is rebooting the phone.
PS: Most likely headsets made by Apple won't be recognized.
Any chance of doing the same work for Peregrine (XT1040)? Very interesting reading by the way...
If you want to know whether peregrine can detect these buttons or not, the answer is yes. Peregrine uses the same chip, if I saw things correctly (which also means it uses the same kernel driver).
If you want a bootable image, I might be able to provide one, but it would be better if someone with a peregrine does that. The patch can be applied as is.
@tpa-moto great work
i personally feel this thread suppose to be in development sub forum.
Hi, great work! This is a sore spot for me because I want to use one of those selfie sticks that plug in as a headset
I followed your instructions and pressing the button of the selfie stick gave no output. It does, however, work normally on another phone I have access to (LG G3 Beat).
I plugged in a headset with a microphone, but no volume buttons. Holding the mic button on the headset activates voice search as it should, but pressing it logs no lines.
While plugging the headset in and out however, I get some erroneous triggers. The jack has 3 black bands, and a sample of the keycodes I'm getting by plugging the jack in and out two times is below.
I know this is not exactly the data you're seeking but it's all I can generate right now, I don't have a headset with a volume button, other than the selfie stick (which is supposed to emulate a volume button, and does so, on the other phone). I'm posting in the hopes that it's useful somehow. Thank you for your hard work and best of luck!
<6>[ 615.271014,0] TPA: value: 13
<6>[ 615.370970,0] TPA: value: 23
<6>[ 615.470890,0] TPA: value: 25
<6>[ 615.570900,0] TPA: value: 26
<6>[ 620.080889,0] TPA: value: 13
<6>[ 620.181147,0] TPA: value: 14
<6>[ 620.280899,0] TPA: value: 14
<6>[ 620.380899,0] TPA: value: 24
<6>[ 620.480906,0] TPA: value: 24
<6>[ 620.580912,0] TPA: value: 24
<6>[ 620.690932,0] TPA: value: 24
<6>[ 620.790923,0] TPA: value: 24
<6>[ 620.890936,0] TPA: value: 26
<6>[ 620.990932,0] TPA: value: 25
<6>[ 621.090917,0] TPA: value: 24
<6>[ 621.191007,0] TPA: value: 25
<6>[ 621.290872,0] TPA: value: 24
<6>[ 621.390886,1] TPA: value: 24
<6>[ 621.500946,0] TPA: value: 24
<6>[ 621.600897,0] TPA: value: 12
<6>[ 621.700952,1] TPA: value: 13
I followed your instructions and pressing the button of the selfie stick gave no output. It does, however, work normally on another phone I have access to (LG G3 Beat).
Click to expand...
Click to collapse
I didn't even know these existed. I just looked it up and it seems that selfie sticks simply send a volume up/down keypress. If nothing gets printed, then the stick is most likely not detected. I see some comments in the code mentioning workarounds for some accessories (e.g. Paypal card reader, Jawbone), probably your selfie stick needs something similar. Needless to say it's really hard to debug the problem without actually owning the stick.
You could try to see if something gets printed when you insert the jack:
Code:
cat /proc/kmsg
(this will print a lot of stuff and then stops. Insert the jack once no lines/almost no lines are printed).
Debug messages are disabled, so it's unlikely you'll see something useful.
I plugged in a headset with a microphone, but no volume buttons. Holding the mic button on the headset activates voice search as it should, but pressing it logs no lines.
Click to expand...
Click to collapse
The chip detects two types of buttons presses and the kernel driver currently does something only for one of them.
If the phone is responding to button presses, the patch I wrote should make no difference as the kernel is already doing what's supposed to do. Most of the headsets with a single button work (e.g. the ones Motorola shipped with this device in some countries). If they have multiple buttons, at most one of them work.
If the phone does not respond to button presses, then this patch should make the kernel print lines similar to the ones you posted.
Also, the patch I posted/applied to the kernel is very simple and doesn't try to avoid spurious events.
I merged this patch to my kernel, however the compiler gave me this while building:
Code:
sound/soc/codecs/tpa6165a2.c:836:13: warning: 'tpa6165_detect_multi_button' defined but not used [-Wunused-function]
static void tpa6165_detect_multi_button(struct tpa6165_data *tpa6165)
^
Is this normal? I'm using GCC 5.2.1 + a modified Uber 5.2 toolchain to build my kernel
That's definitely not normal. Did you use patch to apply the patch? If not, check again what you did.
tpa-moto said:
That's definitely not normal. Did you use patch to apply the patch? If not, check again what you did.
Click to expand...
Click to collapse
Actually i had edited the file manually but i've reverted my commit and then used patch to apply the patch. No more build warnings
Did anyone send him some values privately atleast? I personally did, honestly, i can keep doing what i do right know, building the kernel myself with the patch from gerrit and values for my current headset and i get all the buttons working perfectly, he is just doing you a favor and he is asking just a 1 minute of your life to get those values from /kmsg, because the official implementation of this feature on CM or any other ROM, depends on how much users will report those numbers, i really don't care about this, because, i repeat, that i already did my job and sent him the values of my headsets and i can still compile the kernel myself with the working patch for my headsets. I don't believe there is no one that owns an headset with buttons, just do something useful, instead of flashing 4 different ROMs in 2 hours, flash this kernel and report those values, thanks.
It's also true that probably not many saw this. In any case, I'm not sure we will be able to collect enough values to have anything that can be made "official".
@zackwire Sorry, I didn't bother making an image for peregrine yet.
tpa-moto said:
It's also true that probably not many saw this. In any case, I'm not sure we will be able to collect enough values to have anything that can be made "official".
@zackwire Sorry, I didn't bother making an image for peregrine yet.
Click to expand...
Click to collapse
I don't really understand what you're supposed to do to get the values. Are you able to elaborate a bit more? I'd really like to help out, but I'm not sure what I'm supposed to do.
Also, how many values do you need?
ahmad.o said:
I don't really understand what you're supposed to do to get the values. Are you able to elaborate a bit more? I'd really like to help out, but I'm not sure what I'm supposed to do.
Also, how many values do you need?
Click to expand...
Click to collapse
There isn't much to add to what I already wrote.
Boot the kernel using fastboot and use adb or Terminal Emulator to run the followings:
Code:
su
cat /proc/kmsg | grep TPA
The second command should print a line each you press a button of you headset.
Each button is ideally associated to a value, in practice you'll get different values all close to each other, one per button press. You shouldn't get many different values, once you notice that you can't get anything you didn't get before, you can stop.
Note: I'm also interested in knowing which button generated which line.
Related
Background Info:
ROM: Drizzy's NewVision Touchflo 3D v2.8 ( All pre-req's met / was running perfectly )
Took the back off my phone and battery fell out. Put battery back in and phone will not boot past the htc loop. Upon more research I found out that it cannot mount the sdcard. Checked out the SD card and its fine, plugged it into a computer and re-partitioned it. Still no mmcblk0 in the /dev/block directory. Can't find anyway to get the phone to detect the SD card at all.
/dev/block # ls
loop0 loop2 loop4 loop6 mtdblock0 mtdblock2 mtdblock4
loop1 loop3 loop5 loop7 mtdblock1 mtdblock3 mtdblock5
/ # ls
cache init proc sys
data init.goldfish.rc res system
default.prop init.rc root tmp
dev init.trout.rc sbin
etc lib sdcard
/ # mount /sdcard
mount: mounting /dev/block/mmcblk0p1 on /sdcard failed: No such file or directory
Any ideas?
obviously you can get into recovery, why nor flash a new rom, or the same rom? or just go to the bootloader and go back to stock and start over. if neither of those options work then i am afraid you are screwed
Here's what makes no sense to me... why wouldn't the sd card show up at all in recovery? If its not showing up in recovery then its definately not going to show up after running a new rom, correct?
I'm decently familiar with linux and programming, but not so much with the G1.
The architecture for booting goes:
Bootloader
SPL
Rom
Correct?
EDIT:
And the reason I haven't gone back to stock is I'm worried that if I downgrade from CM 1.4 recovery that I'm going to lose adb ability from the recovery console.
Also, another question, to install a rom from Fastboot, does it have to be a yaffs image?
dmesg shows this alot:
mmc1: Command timeout
Pretty sure this is the root of the problem, not sure what is generating it.
More Dmesg output:
mmc0: Qualcomm MSM SDCC at 0x00000000a0400000 irq 24,0 dma 8
<6>[ 7.620635] mmc0: 4 bit data mode enabled
<6>[ 7.621429] mmc0: MMC clock 144000 -> 50000000 Hz, PCLK 61440000 Hz
<6>[ 7.621887] mmc0: Slot eject status = 1
<6>[ 7.622650] mmc0: Power save feature enable = 1
<6>[ 7.623107] mmc0: DM non-cached buffer at ffc0e000, dma_addr 0x161e7000
<6>[ 7.623901] mmc0: DM cmd busaddr 0x161e7000, cmdptr busaddr 0x161e7300
<4>[ 7.625640] trout_sdslot_switchvdd: Disabling SD slot power
<6>[ 7.626770] mmc1: Qualcomm MSM SDCC at 0x00000000a0500000 irq 26,194 dma 8
<6>[ 7.627227] mmc1: 4 bit data mode enabled
<6>[ 7.628021] mmc1: MMC clock 144000 -> 50000000 Hz, PCLK 61440000 Hz
<6>[ 7.628601] mmc1: Slot eject status = 0
<6>[ 7.629394] mmc1: Power save feature enable = 1
<6>[ 7.629852] mmc1: DM non-cached buffer at ffc0f000, dma_addr 0x161e8000
<6>[ 7.630645] mmc1: DM cmd busaddr 0x161e8000, cmdptr busaddr 0x161e8300
hi... did you solve this problem?... i have the same message from mmc0 and mmc1 and the G1 not recognize the microSD...
Unfortunately, I was never able to solve the problem. I ended up replacing the phone. I'm pretty sure that something shorted out somewhere and the board that reads the SD card was no longer functioning. I tried EVERY trick in the book to try to get it to work.
I ended up (on purpose) bricking the phone completely, to the point of where the light wouldn't even come on with the charger was connected. This way T-Mobile would replace the phone and never know it was modified in any way.
KHannel said:
Unfortunately, I was never able to solve the problem. I ended up replacing the phone. I'm pretty sure that something shorted out somewhere and the board that reads the SD card was no longer functioning. I tried EVERY trick in the book to try to get it to work.
I ended up (on purpose) bricking the phone completely, to the point of where the light wouldn't even come on with the charger was connected. This way T-Mobile would replace the phone and never know it was modified in any way.
Click to expand...
Click to collapse
Don't go about saying that kind of thing in an online forum -- its fraud and you can go to prison for it. YOU ARE NOT AS ANONYMOUS AS YOU THINK YOU ARE!!!
LOL
dhkr123 said:
Don't go about saying that kind of thing in an online forum -- its fraud and you can go to prison for it. YOU ARE NOT AS ANONYMOUS AS YOU THINK YOU ARE!!!
Click to expand...
Click to collapse
LOL. No, fraud is the $6.99 per month they charge for handset insurance and then charge a $50 deductible for a phone that sells for $99 AND require you to give them the phone you are replacing.
Besides, under the "due diligence" laws, there would never be enough reputable evidence to hold up in court.
(Thanks Law School)
Oh and if I want advice, I'll ask for it.
KHannel said:
LOL. No, fraud is the $6.99 per month they charge for handset insurance and then charge a $50 deductible for a phone that sells for $99 AND require you to give them the phone you are replacing.
Besides, under the "due diligence" laws, there would never be enough reputable evidence to hold up in court.
(Thanks Law School)
Oh and if I want advice, I'll ask for it.
Click to expand...
Click to collapse
Thank you for saying that. Seriously, because it's truth.
KHannel said:
LOL. No, fraud is the $6.99 per month they charge for handset insurance and then charge a $50 deductible for a phone that sells for $99 AND require you to give them the phone you are replacing.
Besides, under the "due diligence" laws, there would never be enough reputable evidence to hold up in court.
(Thanks Law School)
Oh and if I want advice, I'll ask for it.
Click to expand...
Click to collapse
You must have gone to a terrible law school, because you are totally wrong.
1) What YOU describe as fraud is nothing but a RIPOFF.
2) Limitations based on a lack of due diligence apply only when there is a... LACK OF DUE DILIGENCE. Evidence is evidence, and a proper search of your equipment after there is sufficient suspicion generated by observing your online behavior to obtain a warrant to go through your property will certainly guarantee recovery of more than sufficient evidence to convict. You also turned over the phone in question to your service provider, who *does* have the right to analyze it to determine the CAUSE OF THE FAILURE... well, there is a chance of surviving this, but I sure wouldn't want to be in that position.
Note:
Tmobile and/or HTC could (and probably do) read this forum. You know what they need to link your statements up to the hardware that you turned in? An IP address. You know how easy that is to get? Trivial. The server logs here (and any router between your computer and this server) all have records. Find your IP address and they find YOU, cross reference with phones turned in, and they find your phone, a little extra care in checking it out turns out confirmation of intentional bricking... supported by your statements here, and files recovered from your home computer (after obtaining a warrant to go through it) and you're finished.
The only reason they don't? Costs more than its worth to them. If they really wanted to though? You'll be finished.
Fancy though, that everyone online is a lawyer, don't you think? I mean there's no firefighters, teachers, garbage collectors, hamburger flippers, or anything else... they're ALL lawyers.
Ok, setting up the old debian chroot is pretty straight forward. I had it up and running within a couple of days. What I really want to try to do is boot into debian natively.
I've been poking around and looking into a few things. I'm thinking it shouldn't be too hard to modify the init.rc to bring up debian instead of the normal android services and whatnot. From looking around it looks to me like init.rc lives in the boot image. So I'm guessing I would need to put together a boot.img with my custom init.rc and any supporting files.
Thoughts?
Should be totally doable. Debugging the boot process is a PITA though. Some things that might help with that:
TTL level serial (2.8v, 3.3v tolerant, I think) is available on the D+/D- lines of the microusb connector when VBUS (usb +5vdc) is not present. You can test a cable with a running N1 -- a couple taps of enter should get the debug> FIQ debugger prompt. For your own build, you'll probably want to enable serial console on ttyMSM0 and disable the FIQ debugger.
Alternatively you could try to dust off the fbconsole support. We never build with it, so it is *possible* that it has some problems, but it might Just Work <tm>.
Until you get a GUI environment up that has touch support, your inputs for on-device for debugging are limited -- volume buttons, power button, trackball button, trackball. The "soft keys" are implemented in userspace, not the kernel -- the kernel just provides a touchpanel driver.
Somebody could probably do an in-kernel softkeyboard, like the guy who did the android-for-vogue stuff way back when did, or perhaps you could convert graffiti-style strokes to keys in-kernel or something suitably fun like that.
I don't currently have the equipment I would need to setup a serial cable for that. Perhaps in the near future though. Thanks for that tip.
Is fbconsole part of the android source, or is a kernel option? I've been digging around for it, and haven't been able to track it down yet.
I poked at this a little over the weekend. Played around with init.rc, but I couldn't get my sdcard to mount without logging in via adb and mounting it by hand. I also decided it would probably be easier to install debian on a partition on the SD card instead of mounting an image off of the card.
I have a lot to learn here, espesially figuring out how to get debian to boot so I expect this will take me some time to figure everything out.
fbconsole is doing some very weird stuff. Scrolling sideways, a very distorted looking image scrolls by. All in all pretty much unusable. I have a mini - micro adapter, and a spare mini usb cable I don't mind donating to science, so having a go at building a serial cable tonight.
You might want to have a look at this
Woot! BOOTS!
Hit default run-level tonight
Next. Configure it so it does more then start cron.
It's already been done, as of 11 days ago...
http://forum.xda-developers.com/showthread.php?t=622474
Could have saved yourself some time with a simple 3 second search...
I hate to break it to you but chrooting into a debian image is not booting into debian. Cute trick, but I had that done the day after I got my nexus.
I'm talking about booting debian from the boot-loader.
Anywho...
I got hung up with getting getty running. Once I installed udev, getty started playing nice.
Debian GNU/Linux 5.0 TheBriaDroid ttyMSM0
TheBriaDroid login:
I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.
NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...
The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.
The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.
Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.
From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?
The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.
One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.
We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.
What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.
For anybody with the time and the hardware, that should be easy enough to try. TheBeano?
There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.
If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.
So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
I will add a little insight without giving too much away
Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...
I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet
Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
I've looked at the schematic fragments from the service manual but they weren't much help. If anyone has a schematic that shows what is connected to the application processor OM pins that would be a big help. Obviously the bootloader sources would be great too!
TheBeano said:
Obviously the bootloader sources would be great too!
Click to expand...
Click to collapse
Come on guys, lets have some input here, and I will give out snippets of info to help, just in case anyone is in any doubt to what I said, take a look at the attached screendump
Odia said:
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
Click to expand...
Click to collapse
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
http://megaupload.com/?d=C0JHS7A8 - service training manual 01/2011
manosv said:
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
Click to expand...
Click to collapse
Hey, off topic here, but i have seen these phones on ebay, chinese own brand of course, but dual boot, runs both android and windows on one phone.
so it is possible for someone who knows how to.... would be very interested in seeing this develop
http://cgi.ebay.co.uk/W6000-Dual-Ca...ile_Phones&hash=item230f1eea0a#ht_3411wt_1139
Fuma said:
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
Click to expand...
Click to collapse
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
TheBeano said:
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
Click to expand...
Click to collapse
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Fuma said:
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Click to expand...
Click to collapse
It's the schematic for a cheap phone with the Mediatek MT6225 processor, the "CSL Blueberry" I think. They have an "i9000" model so maybe that's how it started.
mmm...well if i stumble upon more stuff i'll send your way . it might help.
TheBeano said:
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
Click to expand...
Click to collapse
Yeah, it's got to be the fsa9480. That plus (possibly) the volume/power/etc buttons are the only possibilities. The fsa switches which lines from inside the phone are connected to the micro-USB pins 2 & 3 (aka D+/D-). But it also has (at least) 2 digital outputs called JIG and BOOT which feed back to the CPU. BOOT presumably causes a hardware reset, so the JIG line is free to determine the boot mode.
We know the normal boot is from OneNand. Looking at table 6.3 of the data sheet tells us that the only pin that matters is OM5. Pins OM[4:0] determine which of the 4 different OneNAND boot modes is used, and that mode is the same regardless of OM5. So they are almost certainly just fixed. If OM5 is 0, the chip boots normally (directly from OneNAND). If it is 1, the ROM will first try to negotiate a UART connection, then try a USB connection, and only then (if I'm reading it right), fail over to a normal OneNAND boot.
So it's hard to imagine any scenario other than pin OM5 connected to the JIG output of the fsa9480.
From the Samsung source code linux/drivers/usb/gadget/fsa9480_i2c.h, there are a few interesting resistor choices (I'm not sure what the 5 bits represent; maybe they are for setting/reading the switch state over i2c) :
Code:
1 0 1 1 0 150K UART Cable
1 1 0 0 0 255K Factory Mode Boot OFF-USB
1 1 0 0 1 301K Factory Mode Boot ON-USB
1 1 1 0 0 523K Factory Mode Boot OFF-UART
1 1 1 0 1 619K Factory Mode Boot ON-UART
The 301K case (Factory Mode Boot ON USB) is the familiar "jig" people on xda use. But USB protocol is fairly complex, and since the whole idea of using the fsa switch is very non-USB compliant (the thing sends analog audio over D+/D- lines !) I don't think we can assume anything about what the ROM code does to "negotiate a connection". In addition, I think that all the people who have already looked into this were specifically trying to get into "download mode" (i.e., Loke protocol to talk with Odin). So who knows what else was going on beforehand.
I'm most curious about the behavior with a 619k resistor (Factory Mode Boot ON UART). The nice thing with UART mode is that we already know from TheBeano's thread that there is output at 115200 baud that appears at some point in the boot process. By putting a scope probe on the Tx line and simultaneously watching the text output in a terminal emulator, it should be very simple to see if any kind of negotiating is going on at an early (ROM) bootloader stage. Maybe it involves different baud rate, banging on a key, or pressing/holding a button. But (for someone with time and the right hardware) this is very do-able. If there is any hint of negotiation going on before the NAND-based bootloaders begin, we know we're onto something promising.
Like Odia pointed out, any stuff that we load during the ROM bootloader stage is not being flashed to the OneNAND; it is simply being loaded into RAM and executed. So even with no clue how to write a bootloader, I can imagine writing a "hello world"-grade program to, say, toggle a GPIO. That would clearly establish that the UART bootload procedure works.
So I think its an exciting prospect. Some of it is way beyond my abilities, but there are some easy steps early on that could really generate some intense developer interest.
I've got a I897 and a scope, but no connectors or cables to sacrifice. I may get a breakout board from Sparkfun to mess around with. In the meantime, I'd love to hear if anybody with a resistor/cable combo can sniff out anything interesting.
Also, I'm glad to see some response. I guess my title was a little cryptic, but at first it was just me and the crickets.
Found an interesting post about the ROM bootloader : http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
Another interesting link : http://chdk.wikia.com/wiki/GPL_Disassembling
Lets just say that the ROM code from my phone (Captivate) is definitely talking to the serial ports (all 4) and the USB OTG port.
I just sent off a quick order to Sparkfun for their USB micro-B breakout (the male connector with all 5 pins broken out) and a 3.3V FTDI (USB/serial) board. Just in case I find myself w/ too much time on my hands.
js22 thats actually sounds promising.
waiting for more updates.
Goodluck
e-fuse bits anybody ?
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Oops. I just checked and any read from the SFR address range (0xE0E00000 and up) returns zero. At least if you're using viewmem.
js22 said:
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Click to expand...
Click to collapse
Its using none secure boot and your quite right JTAG access is also none secure.
So, the source code to the IROM would answer all our questions.
It would probably take me a week to reverse engineer it, unfortunately, I don't have the time right now.
The I9000 is a fairly open platform. Would samsung themselves be prepared to give this source code out.
If we could get to a point where any hacker could un-brick their own phones without even having to unscrew the case, using pin 4-5 resistors, and a 3 Volt UART cable or a USB cable, developers would be much more willing to experiment more.
I have a method to force the IROM to try alternative boot methods, and specifically not run the PBL, SBL, but without more information on what to try in order to talk to the IROM directly, is it difficult to proceed further.
To force IROM to ignore PBL and SBL, just do a heimdall dump in Linux and press CTRL-C half way through. It results in a bricked phone, with only the IROM working. I have been told a 301K Resistor will help switch it back to loading PBL and SBL but I have not tested this yet.
Does anyone have contacts within Samsung that might be able to help, or shall I try to use my contacts to source the information?
The IROM looks like it would try to use the USB in OTG mode. Thus expecting the external USB device to be a gadget and not a PC Host. This can have advantages and disadvantages.
1) Disadvantage: Not many Android developers will have USB Gadget test hardware.
2) Advantage: The I9000 itself might be a good USB gadget development tool. Changing the kernel usb driver so that it can respond correctly to commands from the IROM over USB. Potentially, we could then use one I9000 connected directly to another I9000 and the healthy I9000 could automatically unbrick the bricked I9000.
For development though, I think using the UART option would be easier to do, as any Android developer would have a serial port, and then just need a RS232 levels RS232 to 3.3V levels converter, wired up to a Micro-USB connector and the correct resistor on the ID pin.
It is also easier to write a Serial port controlling application than USB controlling applications.
I think that we would still need to reverse engineer the IROM in order to analyze it and discover what the protocol is for loading software directly into the I9000 RAM and running it without going through the boot of IBL/PBL/SBL.
We would then need to write our own boot loader to put in this RAM in order for it to reach a mode where it can program the flash and possibly provide the same functions as the current "download mode".
If we can get it as far as partitioning, and writing the IBL/PBL/SBL. That would be enough.
There are other advantages of this IROM interface. We could use it to root the phone by writing an "su" to the /system folder.
A stepping stone to this could be a "hello world" program that simply controls a GPIO. For example, flashing the LEDs that light the BACK key or writing a message to the screen.
Having the current source code to the IBL/PBL/SBL would really help here as it contains the routines to display characters and graphics on the display etc.
I'm partway through disassembling the ROM boot code, it's pretty interesting! The serial protocol is definitely in there, but I haven't worked with ARM code before so it may take some time. If anyone has already worked it out or is nearly there please let me know now!!
I am currently working on a car mod for my nexus 7, I know how to physically insert the nexus 7 to replace my current in built car sat nav, the only issue is the power! - it will be run from a cigarette lighter which gives enough power to charge it BUT theres one big issue, if I dont use the car for a while the battery will obviously run down to flat and when I start the car up again and it starts charging the screen will just show the charging icon and will not power up into the android interface.
This is a big issue as I cannot re route the power button on the tablet, therefore I need to modify the system files to power on when a charger is plugged in, someone on these forums has already done it with an android device:
http://forum.xda-developers.com/showthread.php?t=1187631
there is says to modify this file:
/system/bin/playlpm
however its not present on the nexus 7! - If anyone can help I would very much appreciate it!
I think you can just use Caffeine for that. There's an option in the settings to auto activate when plugged in.
IGNORE ME: forgot it would be turned off.
Yup, Im assuming I need to modify something at the system level.
Does anyone have any idea what file needs to be modified so that when a charger is plugged in to a nexus it powers on instead of coming up with the charging screen?
I am in need of a similar solution! Any help would be greatly appreciated!
I haven't looked at the N7's kernel yet, but if it's any similar to the Android kernels I've seen so far it can be more or less easiely be done with a small kernel edit.
Basically all you need to do is to give "init" (to "mother of all proceses" in Linux) the same .rc for LPM (="Low Power Mode") as for for "normal boot".
Should be something like copying "init.rc" over "lpm.rc".
HellcatDroid said:
I haven't looked at the N7's kernel yet, but if it's any similar to the Android kernels I've seen so far it can be more or less easiely be done with a small kernel edit.
Basically all you need to do is to give "init" (to "mother of all proceses" in Linux) the same .rc for LPM (="Low Power Mode") as for for "normal boot".
Should be something like copying "init.rc" over "lpm.rc".
Click to expand...
Click to collapse
Any more progress on this?
Looking for the same solution, was anyone successful in doing this?
zedix79 said:
Looking for the same solution, was anyone successful in doing this?
Click to expand...
Click to collapse
My particular use case was for my car install, and so I just decided to go with externalizing the power button. I have an external power supply (P-2140) that can pulse/close the circuit at ignition on and off that I plan on using from my old CarPC install. Here's my thread about power button externalization:
http://forum.xda-developers.com/showthread.php?t=1945947
I'm going to mount a button on the dash as well so I can wake the tablet from off. My goal is to have the tablet sleep for 2-3 days in airplane mode and then turn off when it has exceeded this sleep time. This way I'll only have to use this button in cases where I haven't driven my car for a weekend or so.
Add me to the list of people wanting a way to boot up the device when plugged in! (car-install).
Had a quick look at all the custom kernels on the forums here, and none of them mention that they support this. I wonder how hard it would be? Who's taking feature requests!
Would running it through constant power instead of switched power solve our issue? Would it continually drain the battery even if the tablet is @100% battery?
So, this is all from memory, but I looked at the init.rc (I believe) and it had a line that was something like
usb power
system_start charge
and then for many of the other options, it had system_start main.
Remember I'm doing this from memory, so I'm paraphrasing here. Anyway, I changed the action to system_start main (the same that I'd seen). It didn't work, but when I reopened the file (after boot) my edits reverted to default.
I just opened a thread on edits to system files not being saved after they are changed. Anyway, I'm thinking this may be the setting we need. If anyone can't find what I'm talking about, I'll look for the file and the specifics again. If anyone does find the actual information, could you please post. I know my actual names are incorrect.
Yeah, you can't really edit the files in / (root dir) as those are the initial ram disk the kernel boot off, i.e. they are only kind of temporaray in memory, on a reboot the init ram disk is remounted / recreated from the kernel image - hence changes are not persistant.
You need to edit the initrd image in the kernel to actually change those files.
zedix79 said:
Had a quick look at all the custom kernels on the forums here, and none of them mention that they support this. I wonder how hard it would be? Who's taking feature requests!
Click to expand...
Click to collapse
Plus 1 Request...
+2 ...
Someone got a link to the original kernel sources for a lazy cat?
Might take a look when/if I got some time - no promises though, time's very limited ATM.
HellcatDroid said:
Someone got a link to the original kernel sources for a lazy cat?
Might take a look when/if I got some time - no promises though, time's very limited ATM.
Click to expand...
Click to collapse
You can get some instructions and kernel files here I believe:
http://source.android.com/source/building-kernels.html
Guys.... any news on this?
Any updates? I'm in the middle of a similar project
Godswrath said:
Would running it through constant power instead of switched power solve our issue? Would it continually drain the battery even if the tablet is @100% battery?
Click to expand...
Click to collapse
Yes but this defeats the purpose as we are using "external power connected" as a trigger for the displays. In my case I'm running torque and a recording app when power is conected and killing them when disconnected. This way when i start the car the recording will start and Torque will display my gauges and when i turn off the car the apps get killed and the phone turns off. (therefore saving battery) however when we start the car again android boots into "power manager" (the big green battery screen) Android at this point its not booted so daemons are not started and we cant do anymore triggering requiring us to manually long press the power button to continue normal operation.
* My mod installation is persistent. This is an old phone that i intent to leave there at all times. (no GSM conectivity)
I much rather have it be automatically
pheonixsingh said:
Yup, Im assuming I need to modify something at the system level.
Does anyone have any idea what file needs to be modified so that when a charger is plugged in to a nexus it powers on instead of coming up with the charging screen?
Click to expand...
Click to collapse
I have been messing around with this for the whole day. I wil ldo some more investigation tomorrow i believe that while we cant touch the virtual disk files (because they are mounted at root) pm.jar is persistent and we should be able to make some changes in java and put the modified file back having it boot this way without actually having to compile a kernell.
If anyone wants to help reply here (i subscribed to thread)
This is of uttermost importance to me and any help would be appreciated)
Some pics of my project >> dropbox.com/s/ivx9mrry2671g15/2012-12-22%2020.28.14.jpg (couldn't post URL because new user)
phone >> samsung r720
edit:
One question. If i externalize the power button like OP did.... will i still have to long press or could i have it be a flippable switch. ( i could live with that)
---------- Post added at 05:11 PM ---------- Previous post was at 04:54 PM ----------
doing some research I found out that this is more related to firmware than to OS since it has to do with BIOS and POST (not sure if those are the appropiate terms when talking about a phone)
Starting to think a hardware solution might be more approachable.
>>leaving this here for reference
tombtalk.net/?p=627
For someone who has recompiled a kernel, this should be easy. There is one setting in one file that needs to be changed. I can't remember it now, but if someone wants I'll look for it. Basically the line reads something like:
on power = boot charge
and needs to be changed to
on power = boot system
http://www.one-netbook.com/ or http://en.one-netbook.com/
One Mix Yoga
(mini) laptop w/ 360 degree hinge, optional pen support with 2048 pressure sensitivity
Windows 10 Home
7" 1920x1200 Goodix Capacitive 9111 4020 touchscreen (ACPI\GDIX1001, VEN_GDIX, DEV_1001)
Bosch 0200 acceleormeter
Intel x5-Z8350 on BIOS 5.11 05/21/2018
8GB (DDR3(?)) single dimm
128GB eMMC - hynix hdg8a4
microUSB charging (5V/3A)
usb typeC for data only, cannot charge via typeC
microSDXC slot
full-size USB 3.0
microHDMI out
audio/sound (Intel UCM RT5651), 3.5mm jack
HAILUCK usb keyboard
bluetooth
wifi - Intel Dual Band Wireless AC 3165
orientation sensor - ?
fan sensor - ?
spam FN+F7 key to get UEFI boot menu to show up
UEFI/BIOS is bare bones, no settings besides secure boot/boot ordering
Linux distros
(tested on ubuntu-mate-18.04-desktop-amd64)
Boots without issues.
Wifi/Bluetooth detected out of box
Display is flipped 90deg (portrait), rotation sensor is detected and needs to be fixed. ubuntu 18.04 GNOME3 can autorotate, MATE/LXDE/... doesn't use the sensor and doesn't autorotate
usb type C, microSDXC, microUSB charging works. have not tested microHDMI port yet
Hibernate works (as long as you have >8GB swap configured)
Sleep seems to work but buggy (see bugs below)
Known fixes:
Display & touchscreen rotation
create this file in /lib/udev/hwdb.d/61-sensor-local.hwdb, then execute "systemd-hwdb update" and reboot
see https://www.aixin.fr/jipeblog/?p=119, need to give the sensor a better name
Code:
sensor:modalias:acpi:BOSC0200*:dmi*
ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1
Sound (speakers, 3.5mm) (partial fix)
Need to install bytcr-rt5651 and use a newer (mainline) kernel (4.17.5 works, 4.15.x does not)
https://github.com/plbossart/UCM/blob/master/bytcr-rt5651/README
Sound can be controlled within linux. Keyboard volume keys do not work properly
Speaker works, but is distorted. still need to investigate
3.5mm works without any distortion
brightness control and pwm-lpss (intel low power subsystem) (available on 4.15+ kernels)
Add pwm-lpss, pwm-lpss-platform, pwm-lpss-pci to initram modules to fix
https://techtablets.com/forum/reply/69539/
Known Bugs with no fixes (yet)
Fan does not work (not detected by lwsensors, does not turn on)
Sleep seems to work, but battery drains fast. i2c floods after suspend, touchscreen works intermittently. wifi works after sleep. 3%/hour drain during sleep, not good
If you close lid during sleep/hibernate mode, lid sensor always wakes up device (even if lid-closing is configured to do nothing)
Grub2 menu sometimes shows up, sometimes doesn't (system always boots into linux without issues)
Keyboard keys work for brightness/backlight/FN, but not for volume)
Touchscreen (and pen)vworks for the most parts, but some menu won't register a "touch" (need the left click mouse button to activate the menu)
Android-x86
(tested on android-x86_64-8.1-rc1.iso)
you can boot with 'nomodeset' parameter, UI is sluggish since hardware acceleration is disabled
http://www.android-x86.org/document...-when-you-have-problems-with-your-graphiccard
(tested on Bliss-v10.1-Beta-android_x86_64-NIGHTLY-20180713-0052_k4.16.5-blissified.iso )
(newer kernel), dont need to use 'nomodeset'. .definitely works better, UI is very responsive
no sound/bluetooth/rotation
wifi and brightness control works
<other>
Thanks for all the posts...
Just ordered one of these little guys....
So, very interested in getting linux on it and working well after I receive it in a few weeks....
Any thought of trying Linux Mint on it?
I've found it seems to work well on other little laptops.
Mark
ArchiMark said:
Thanks for all the posts...
Just ordered one of these little guys....
So, very interested in getting linux on it and working well after I receive it in a few weeks....
Any thought of trying Linux Mint on it?
I've found it seems to work well on other little laptops.
Mark
Click to expand...
Click to collapse
linux mint may help with HiDPI/gpu resources, but you'll likely run into the same root issues listed above.
still trying to resolve the following items, but it's enough to be daily driver for me (aka don't want to mess with linux mint)
- trying other bytcr-rt5651 hifi. this works best, but it's still very soft, likely missing the gpio amplifier config
https://github.com/plbossart/UCM/issues/13#issuecomment-383365511
- pen doesn't work properly (is detected, but the drawing function seems to be semi broken)
- power-drain during sleep (from other cherrytrail atom devices, looks like it's not solvable due to s3 sleep issues)
once I iron out the speaker issue, i'll try an android-x86 build
Installed linux mint 19 on my new Yoga....
As expected, the login screen is rotated sideways, but changed display setting so that once I login, it is correct orientation.
Overall, works fine, except audio, but have to check the other functions you mention.
Thanks for your continued info and input.
Tried to get the audio working per the directions shown below from:
https://github.com/plbossart/UCM/issues/13#issuecomment-383365511
Post by F5LVG on Jun 21
Update Lubuntu 18.04
Jumper EZBook 2, Intel Atom x5-Z8350 processor, bytcr-rt5651 sound card
Download the folder bytcr-rt5651 ( https://github.com/plbossart/UCM/archive/master.zip )
Copy directory to UCM location
sudo cp -rf ../bytcr-rt5651 /usr/share/alsa/ucm
Update asound.state
sudo cp asound.state /var/lib/alsa
Restart
Use the pulseaudio volume control to choose the output (speaker or headphone).
Also, updated kernel as you suggested to 4.17.5.
However, I still cannot move the volume slider. So, no sound.....
Any suggestion?
ArchiMark said:
Tried to get the audio working per the directions shown below from:
https://github.com/plbossart/UCM/issues/13#issuecomment-383365511
Post by F5LVG on Jun 21
Update Lubuntu 18.04
Jumper EZBook 2, Intel Atom x5-Z8350 processor, bytcr-rt5651 sound card
Download the folder bytcr-rt5651 ( https://github.com/plbossart/UCM/archive/master.zip )
Copy directory to UCM location
sudo cp -rf ../bytcr-rt5651 /usr/share/alsa/ucm
Update asound.state
sudo cp asound.state /var/lib/alsa
Restart
Use the pulseaudio volume control to choose the output (speaker or headphone).
Also, updated kernel as you suggested to 4.17.5.
However, I still cannot move the volume slider. So, no sound.....
Any suggestion?
Click to expand...
Click to collapse
go to the sound settings->hardware or output, you may need to select the new output device
paperWastage said:
go to the sound settings->hardware or output, you may need to select the new output device
Click to expand...
Click to collapse
Thanks, tried this, but no go....there's nothing for me to select....strange...
Meanwhile, I'm finding LM 19 is acting up with the newer kernel....when I restart, it does not always boot up properly/completely to login screen.
Reinstalled LM 19, thinking maybe something got messed up. But having same problem again.
Maybe time to try Debian or Ubuntu?.....
UPDATE:
Downloading Ubuntu-Mate now....will give it a try....
Tried Ubuntu Mate install twice....but both times it has problems...various things run slow or some windows that pop up won't close....
Got other error messages...
I did verify checksum on download.....so, not sure what the problem is....
Think I'll try another distro.....
Oh well....
Good news!
Decided to try Linux Mint 19 Cinnamon again...since overall, it has worked so well in the past on other little laptops...
Upgraded kernel to 4.17.5 as you suggested and did the other steps mentioned in prior post.
The thing that I think made this work this time, is I noticed a post in the https://github.com/plbossart/UCM/issues/13 thread by sundarnagarajan on Oct 27, 2017.
He mentioned blacklisting a file 'snd_hdmi_lpe_audio' as he said it crashes pulseaudio.
All I know is that after I did this and rebooted, VOILA! I heard a chime sound when LM 19 booted up!!!
So, that's progress....
Do you think there's any benefit to updating kernel any further, I see that version 4.18.6 is available now....
Thanks.
ArchiMark said:
Good news!
Decided to try Linux Mint 19 Cinnamon again...since overall, it has worked so well in the past on other little laptops...
Upgraded kernel to 4.17.5 as you suggested and did the other steps mentioned in prior post.
The thing that I think made this work this time, is I noticed a post in the https://github.com/plbossart/UCM/issues/13 thread by sundarnagarajan on Oct 27, 2017.
He mentioned blacklisting a file 'snd_hdmi_lpe_audio' as he said it crashes pulseaudio.
All I know is that after I did this and rebooted, VOILA! I heard a chime sound when LM 19 booted up!!!
So, that's progress....
Do you think there's any benefit to updating kernel any further, I see that version 4.18.6 is available now....
Thanks.
Click to expand...
Click to collapse
sound via speaker works perfectly without distortion?
I did 4.17.x to get the newest changes for pwm-lpss to get backlight hurting... doesn't hurt to be on the bleeding edge?
paperWastage said:
sound via speaker works perfectly without distortion?
Click to expand...
Click to collapse
Tried some videos ad sound is distorted.......
Think there's any hope to get this fixed?
I did 4.17.x to get the newest changes for pwm-lpss to get backlight hurting... doesn't hurt to be on the bleeding edge?
Click to expand...
Click to collapse
backlight hurting or working?......it works for me now....
Install
I got a one mix yoga recently, and tried to boot to a linux iso on an USB external cd, but I got lost in the UEFI boot order and what to do next, so I never managed to get the installation running. Would anyone tell me what to do to get it to boot?
OneMix 2S
One Mix has an update generation, it is OneMix 2S. CPU is Core m3-8100Y, 8GB RAM, and ROM is 256GB PCIE SSD. You can surf one-netbook on Google to get into their website
---------- Post added at 09:50 AM ---------- Previous post was at 09:47 AM ----------
AnalogDialog said:
I got a one mix yoga recently, and tried to boot to a linux iso on an USB external cd, but I got lost in the UEFI boot order and what to do next, so I never managed to get the installation running. Would anyone tell me what to do to get it to boot?
Click to expand...
Click to collapse
Maybe you should talk to their service team
---------- Post added at 10:05 AM ---------- Previous post was at 09:50 AM ----------
ArchiMark said:
Installed linux mint 19 on my new Yoga....
As expected, the login screen is rotated sideways, but changed display setting so that once I login, it is correct orientation.
Overall, works fine, except audio, but have to check the other functions you mention.
Thanks for your continued info and input.
Click to expand...
Click to collapse
audio is fine, maybe some problems appear on your audio-jack and speaker
I have one of these little machines and run Manjaro Cinnamon 18.0.x on it.
Most everything, including hibernation and sound, work fine. It's the best Linux Desktop experience I had so far.
The only issues I have:
Also facing battery drain during suspend, even with suspend-then-hibernate
Pen doesn't work at all
Fan runs, but system still gets quite hot
Wifi remains connected, yet drops all connections occasionally. Only manual disconnect and connect help
Of these issues, the pen is my biggest pain. Does anyone have a clue which files or modules are responsible and what is special in 18.04.2 to make it work there?