330 lines
24 KiB
HTML
330 lines
24 KiB
HTML
|
<!doctype html>
|
||
|
|
<html lang="en-gb">
|
||
|
|
<head>
|
||
|
|
<meta charset="UTF-8" />
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
|
|
<link href="https://blog.polynom.me/css/index.css" rel="stylesheet" integrity="sha384-R7KUcezOBiIXJ95JUBiXFdX0mMReehb8omi2xIGyZ6mbgXtQ3spxTx4c9BfffIA8" />
|
||
|
|
|
||
|
|
|
||
|
|
<link rel="alternate" type="application/rss+xml" title="blog.polynom.me Atom feed" href="https://blog.polynom.me/atom.xml">
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<meta property="og:description" content="" />
|
||
|
|
<meta property="og:title" content="Mainline Hero Part 0 - Modern Linux For My Galaxy S7" />
|
||
|
|
<title>Mainline Hero Part 0 - Modern Linux For My Galaxy S7</title>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<script type='text/javascript' async src='https://blog.polynom.me/js/MathJax/MathJax.js?config=TeX-AMS_CHTML' integrity="sha384-3lJUsx1TJHt7BA4udB5KPnDrlkO8T6J6v/op7ui0BbCjvZ9WqV4Xm6DTP6kQ/iBH"></script>
|
||
|
|
<script type='text/x-mathjax-config'>MathJax.Hub.Config({'CommonHTML': {scale: 100}, tex2jax: {inlineMath: [['$','$']]}});</script>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="flex flex-col p-2 md:p-8 items-start md:w-4/5 mx-auto">
|
||
|
|
<!-- Header -->
|
||
|
|
<div class="flex flex-row self-center">
|
||
|
|
<img class="w-12 h-12 md:w-24 md:h-24 rounded-lg" src="https://blog.polynom.me/img/avatar.jpg" integrity="sha384-uiNteVXosQ2+o/izp41L1G9VwuwYDYCOPxzFWks058DMUhW7KfQXcipM7WqgSgEZ" alt="Profile picture"/>
|
||
|
|
<div class="ml-4 self-center">
|
||
|
|
<a class="self-center text-2xl font-bold" href="/">PapaTutuWawa's Blog</a>
|
||
|
|
|
||
|
|
<ul class="list-none">
|
||
|
|
<li class="inline mr-8"><a href="/">Posts</a></li>
|
||
|
|
<li class="inline mr-8"><a href="https://blog.polynom.me/atom.xml">RSS</a></li>
|
||
|
|
<li class="inline mr-8"><a href="https://polynom.me">About</a></li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<!-- Container for posts -->
|
||
|
|
<div class="mx-auto mt-4 w-full md:max-w-prose">
|
||
|
|
<h1 class="text-indigo-400 text-3xl">Mainline Hero Part 0 - Modern Linux For My Galaxy S7</h1>
|
||
|
|
|
||
|
|
<span class="text-md mt-2">Posted on 2019-07-01</span>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="mt-6">
|
||
|
|
<div class="prose lg:prose-lg text-md text-white">NOTE: This post uses the JavaScript library MathJax to render math equations</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<!-- Actual article -->
|
||
|
|
<article class="prose lg:prose-lg text-white mt-4">
|
||
|
|
<p>Ever heard of <a href="https://postmarketos.org/">PostmarketOS</a>? If not, then here's a short summary:
|
||
|
|
PostmarketOS aims to bring <em>"[a] real Linux distribution for phones and other mobile devices [...]"</em> to,
|
||
|
|
well, phones and other mobile devices.</p>
|
||
|
|
<span id="continue-reading"></span>
|
||
|
|
<p>Ever since reading about it, I've been intrigued by the idea of running a real Linux distro
|
||
|
|
with my UI of choice, be it <em>Plasma</em> or <em>Unity</em>, on my phone. Perhaps even running the device
|
||
|
|
without any proprietary firmware blobs. So, I tried my best at contributing to PostmarketOS, which
|
||
|
|
resulted in 3 MRs that have been accepted into master (Sorry for forgetting to bump the pkgver...).</p>
|
||
|
|
<p>With this series - if I manage to not break my phone - I want to document what I, someone
|
||
|
|
who has absolutely no idea what he is doing, learned about all this stuff, how I went about it
|
||
|
|
and what the results are.</p>
|
||
|
|
<h2 id="mainline-hero-0-preparations">Mainline Hero #0 - Preparations</h2>
|
||
|
|
<p>Before I can even think about trying to make mainline Linux run on my <em>Galaxy S7</em>, we should think
|
||
|
|
about how we can diagnose any issues that the kernel or the bootloader might have. And how do
|
||
|
|
professionals debug? Exactly! With <strong>a lot</strong> of <code>printf()</code> statements. But how can we retrieve those
|
||
|
|
from the device?</p>
|
||
|
|
<h3 id="getting-output">Getting Output</h3>
|
||
|
|
<p>While preparing myself for this task, I learned that there are a couple of ways.</p>
|
||
|
|
<p>One is called <a href="https://wiki.postmarketos.org/wiki/Mainlining_FAQ#Writing_dmesg_to_RAM_and_reading_it_out_after_reboot"><em>RAM console</em></a>. What it does is just dump everything that the kernel prints into a
|
||
|
|
reserved region of memory, which can later be retrieved by reading from <code>/proc/last_kmsg</code> with a
|
||
|
|
downstream kernel. </p>
|
||
|
|
<p>The other one is via a <a href="https://wiki.postmarketos.org/wiki/Serial_debugging">serial cable</a>. This sounded
|
||
|
|
pretty difficult at first, the reason being that I have no idea about hardware, besides the occasional
|
||
|
|
<strong>PC</strong> hardware talk. I imagined a cable coming out of a box, packed to the brim with electronics
|
||
|
|
doing some black magic.</p>
|
||
|
|
<p>The reality is - thankfully - much simpler. It is, basically, just a normal USB cable. I mean: <em>USB</em> literally
|
||
|
|
stands for <a href="https://en.wikipedia.org/wiki/USB"><em>Universal Serial Bus</em></a>. But how come my PC does not
|
||
|
|
read those kernel logs when I plug in my phone?</p>
|
||
|
|
<p>As it turns out, there is a component built into my phone which decides exactly what data flows from my
|
||
|
|
phone to the PC. Reading the <a href="https://forum.xda-developers.com/galaxy-s7/how-to/guide-samsung-galaxy-s7-uart-t3743895">XDA post</a> which the PostmarketOS Wiki linked helped understand that my
|
||
|
|
device contains a <em>MUIC</em>, a chip which multiplexes the data lines of the USB cable towards different
|
||
|
|
"subsystems". As I later learned, the USB standard for connectors of type Micro Type B requires 5 pins:
|
||
|
|
power, ground, RX, TX and ID. Power and ground should be self-explanatory if you know anything
|
||
|
|
about electronics (I don't). RX and TX are the two data lines that USB uses. As USB is just a serial
|
||
|
|
connection, only <strong>one</strong> line is used for sending and one for receiving data. The ID line is the interesting
|
||
|
|
one: it tells the MUIC what subsystem it should multiplex the data lines to.</p>
|
||
|
|
<p><a href="https://web.archive.org/web/20190120234321/https://pinouts.ru/PortableDevices/micro_usb_pinout.shtml">Pinout diagram</a> of the Micro Type B connector:</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span> _______________
|
||
|
|
</span><span> / \
|
||
|
|
</span><span>| 1 2 3 4 5 |
|
||
|
|
</span><span>+--|--|--|--|--|--+
|
||
|
|
</span><span> | | | | +-o Ground
|
||
|
|
</span><span> | | | +----o ID
|
||
|
|
</span><span> | | +-------o D+ (Data)
|
||
|
|
</span><span> | +----------o D- (Data)
|
||
|
|
</span><span> +-------------o VCC (Power)
|
||
|
|
</span></code></pre>
|
||
|
|
<p>According to the XDA post, the MUIC switches to serial - used for dumping output of the bootloader and the
|
||
|
|
kernel - if it measures a resistance of 619kOhm attached to the ID pin. So, according to the diagram in the
|
||
|
|
post, I built a serial cable.</p>
|
||
|
|
<p>But how did the author of the XDA post know of the exact resistance that would tell the MUIC to switch to
|
||
|
|
serial? If you <code>grep</code> the
|
||
|
|
<a href="https://raw.githubusercontent.com/ivanmeler/android_kernel_samsung_herolte/lineage-15.1/arch/arm64/configs/exynos8890-herolte_defconfig"><em>S7</em>'s defconfig</a>,
|
||
|
|
for <code>MUIC</code>, then one of the results is the KConfig flag <code>CONFIG_MUIC_UNIVERSAL_MAX77854</code>.
|
||
|
|
If we then search the kernel tree for the keyword <code>max77854</code>, we find multiple files; one being
|
||
|
|
<code>drivers/mfd/max77854.c</code>. This file's copyright header tells us that we deal with a <em>Maxim 77854</em> chip. Judging
|
||
|
|
from the different files we find, it seems as if this chip is not only responsible for switching between serial
|
||
|
|
and regular USB, but also for e.g. charging (<code>drivers/battery_v2/include/charger/max77854_charger.h</code>).</p>
|
||
|
|
<p>However, the really interesting file is <code>drivers/muic/max77854.c</code>, since there we can find an array of structs
|
||
|
|
that contain strings. Sounds pretty normal until you look at the strings more closely: One of the strings is
|
||
|
|
the value <code>"Jig UART On"</code>:</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||
|
|
</span><span>#if defined(CONFIG_SEC_FACTORY)
|
||
|
|
</span><span> {
|
||
|
|
</span><span> .adc1k = 0x00,
|
||
|
|
</span><span> .adcerr = 0x00,
|
||
|
|
</span><span> .adc = ADC_JIG_UART_ON,
|
||
|
|
</span><span> .vbvolt = VB_LOW,
|
||
|
|
</span><span> .chgdetrun = CHGDETRUN_FALSE,
|
||
|
|
</span><span> .chgtyp = CHGTYP_NO_VOLTAGE,
|
||
|
|
</span><span> .control1 = CTRL1_UART,
|
||
|
|
</span><span> .vps_name = "Jig UART On",
|
||
|
|
</span><span> .attached_dev = ATTACHED_DEV_JIG_UART_ON_MUIC,
|
||
|
|
</span><span> },
|
||
|
|
</span><span>#endif /* CONFIG_SEC_FACTORY */
|
||
|
|
</span><span>[...]
|
||
|
|
</span></code></pre>
|
||
|
|
<p>The keyword <code>ADC_JIG_UART_ON</code> seems especially interesting. Why? Well, the driver has to know what to do
|
||
|
|
with each measured resistance. It would make sense that we call the constant which contains the resistance
|
||
|
|
something like that. Additionally, it is the only constant name that does not immediately hint at its
|
||
|
|
value or function.</p>
|
||
|
|
<p>So we search the kernel source for this keyword. Most occurences are just
|
||
|
|
drivers using this constant. But one hit shows its definition: <code>include/linux/muic/muic.h</code>. There we
|
||
|
|
find on <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/b51cf88008606ebac535785ff549b9f55e5660b4/include/linux/muic/muic.h#L106">line 106</a>
|
||
|
|
a comment which states that this constant represents a resistance of 619kOhm.</p>
|
||
|
|
<p>To actually build the serial cable, we need to have a USB Type B male connector that we can solder our cables to.
|
||
|
|
My first thought was to buy a simple and cheap USB Type B cable, cut it, remove the isolation and solder my
|
||
|
|
connectors to it. I, however, failed to notice that the Type A part of the cable - the one you plug into e.g.
|
||
|
|
your PC - only has 4 pins, while the Type B part has 5. After stumbling upon some random diagram, I learned that
|
||
|
|
for regular USB connectivity, such as connecting your phone to your PC, the ID pin is not needed, so it is left
|
||
|
|
disconnected. As this plan failed, I proceeded to buy a USB Type B male connector. Since I bought it on the
|
||
|
|
Internet and the seller did not provide a diagram of what pad on the connector connects to what pin, I also
|
||
|
|
ordered a USB Type B female breakout board.</p>
|
||
|
|
<p>After all parts arrived, I used a digital multimeter to measure the resistance between each pad on the connector
|
||
|
|
and on the breakout board. Since I have no idea about electronics, let me explain: Resistance is defined as
|
||
|
|
$R = \frac{U}{I}$, where $R$ is the resistance, $U$ the voltage and $I$ the current. This means that we should
|
||
|
|
measure - practically speaking - infinite resistance when no current is flowing and some resistance $R \gt 0$
|
||
|
|
when we have a flowing current, meaning that we can test for continuity by attempting to measure resistance.</p>
|
||
|
|
<p>After some poking around, I got the following diagram:</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span> +---------o VCC
|
||
|
|
</span><span> | +-----o D+
|
||
|
|
</span><span> | | +-o GND
|
||
|
|
</span><span> ___|___|___|___
|
||
|
|
</span><span> / ? ? ? \
|
||
|
|
</span><span>| ? ? |
|
||
|
|
</span><span>+------|---|------+
|
||
|
|
</span><span> | +---o ID
|
||
|
|
</span><span> +-------o D-
|
||
|
|
</span></code></pre>
|
||
|
|
<p><img src="/img/serial-cable.jpg" alt="The "Serial Cable"" /></p>
|
||
|
|
<p>Since the data that the serial port inside the phone is coming in using a certain protocol, which also includes
|
||
|
|
timing, bit order and error correcting codes, we need something to convert this data into something that is
|
||
|
|
usable on the host. Since the USB specification for data may differ from what we actually receive, we can't just
|
||
|
|
connect the phone's D- and D+ lines to the host USB's D- and D+. Hence the need for a device which does this
|
||
|
|
conversion for us and also deals with the timing of the data: The tiny board to which all cables lead to
|
||
|
|
basically just contains an <em>FT232RL</em> chip from <em>FTDI</em>. It is what does all the conversion and timing magic.</p>
|
||
|
|
<p>Since I don't want to accidentally brick by phone by frying it with 3.3V or 5V - though I think that damaging
|
||
|
|
the hardware with 5V is pretty difficult - I did not connect the USB's 5V to the <em>FT232</em>'s VCC port.</p>
|
||
|
|
<p>Booting up the device, we start to see data being sent via serial!</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||
|
|
</span><span>CP Mailbox Debug
|
||
|
|
</span><span>0x10540180 : 0xdca7b414 0x 804f99f
|
||
|
|
</span><span>0x10540184 : 0xdeb36080 0x8112566f
|
||
|
|
</span><span>0x10540188 : 0xf4bf0800 0x2534862d
|
||
|
|
</span><span>0x1054018C : 0x61ff350e 0x1208fd27
|
||
|
|
</span><span>0x10540190 : 0x17e60624 0x18121baf
|
||
|
|
</span><span>0x105C0038 : 0x3bd58404 0x5674fb39
|
||
|
|
</span><span>CP BL flow
|
||
|
|
</span><span>0x10920014 : 0x79dab841 0x9b01b3fd
|
||
|
|
</span><span>0x10800028 : 0xffbd34b1 0x9fd118cc
|
||
|
|
</span><span>Resume el3 flow
|
||
|
|
</span><span>EL3_VAL : 0xdcfee785 0xfbb6b0a2 0xccf99641
|
||
|
|
</span><span>muic_register_max77854_apis
|
||
|
|
</span><span>muic_is_max77854 chip_id:0x54 muic_id:0xb5 -> matched.
|
||
|
|
</span><span>[MUIC] print_init_regs
|
||
|
|
</span><span> INT:01 00 00 ST:1d 00 00 IM:00 00 00 CDET:2d 0c CTRL:1b 3b 09 b2 HVCT:00 00 LDO0:47
|
||
|
|
</span><span>
|
||
|
|
</span><span>MUIC rev = MAX77854(181)
|
||
|
|
</span><span>init_multi_microusb_ic Active MUIC 0xb5
|
||
|
|
</span><span>[...]
|
||
|
|
</span></code></pre>
|
||
|
|
<p>Nice! We can see what <em>SBOOT</em>, the bootloader that <em>Samsung</em> uses, tells us. But for some reason, I wasn't
|
||
|
|
able to get into the <em>SBOOT</em> prompt to tell the kernel to dump everything via serial. While the XDA post
|
||
|
|
used the programm <code>minicom</code>, which I could use to get <em>SBOOT</em> output, it never seemed to send the carriage
|
||
|
|
returns while I was pressing the return key like crazy. So what I did was try to use a different tool to
|
||
|
|
interact with the serial converter: <code>picocom</code>. And it worked! </p>
|
||
|
|
<p>Although I set the kernel parameters to output to the TTY device <code>ttySAC4</code>, just like the XDA post said,
|
||
|
|
I did not receive any data.</p>
|
||
|
|
<h3 id="device-tree">Device Tree</h3>
|
||
|
|
<p>So we can just try and boot mainline on the phone then, yes? With a very high probability: no. The reason being
|
||
|
|
that the kernel has no idea about the actual hardware inside the phone.</p>
|
||
|
|
<p>This may seem weird as you don't have to tell your kernel about your shiny new GPU or about your RAM. The reason
|
||
|
|
is that your PC is designed to be modular: You can swap the CPU, the RAM and even the attached devices, like
|
||
|
|
your GPU. This means that on X86, the CPU is able to discover its hardware since there is only one bus for
|
||
|
|
attaching devices (ignoring RAM and the CPU): the PCI bus. How does the CPU know about its RAM?
|
||
|
|
The RAM-modules are swappable, which means that the CPU cannot anticipate just how much RAM you
|
||
|
|
have in your system. These information get relayed, perhaps via the MMU, to the CPU.</p>
|
||
|
|
<p>Can't we just probe the available memory in an ARM SoC? Technically yes, but it would take a lot
|
||
|
|
of time if we have a modern 64 bit CPU. Moreover, how do you know that a probed memory location
|
||
|
|
is not a memory mapped device? Wouldn't it make sense to bake this data into the SoC then? Here
|
||
|
|
again: not really. The reason is that the SoCs are vendor specific. This means that the vendor
|
||
|
|
basically just buys the rights to put the CPU into their SoC. The rest is up to the vendor. They
|
||
|
|
can add as much RAM as they want, without the CPU designer having much input. This means that the
|
||
|
|
data must not be <strong>hardcoded</strong> into the CPU.</p>
|
||
|
|
<p>On ARM and probably most other microprocessors devices can be memory mapped, which means that they respond to
|
||
|
|
a certain region of memory being written to or read from. This makes auto-discovering devices quite difficult
|
||
|
|
as you would have to probe <strong>a lot</strong> of memory regions.</p>
|
||
|
|
<p>As an example: Imagine we can access 4 different locations in memory, each holding 1 byte of data. These regions
|
||
|
|
are at the memory addresses <code>0x1</code> to <code>0x4</code>. This means that we would have to probe 4 memory locations. Easy,
|
||
|
|
right?
|
||
|
|
Not exactly. We would have to probe 4 times to discover 4 possible memory mapped areas with a width of 1 byte.
|
||
|
|
If we allow a width of 2 bytes, then we would have to probe 3 different regions: <code>0x1</code>-<code>0x2</code>, <code>0x2</code>-<code>0x3</code> and
|
||
|
|
<code>0x3</code>-<code>0x4</code>.
|
||
|
|
This assumes that memory maps need to be directly next to each other. Otherwise we would need to use the
|
||
|
|
binomial coefficient.</p>
|
||
|
|
<p>This results in 10 (4x 1 byte, 3x 2 bytes, 2x 3 bytes and 1x 4 bytes) different probing attempts to discover
|
||
|
|
possible memory mapped devices. This does not seem much when we only have a 2 bit CPU, but in the case of the
|
||
|
|
<em>S7</em>, we have a 64 bit CPU; so we would have to probe about $\sum_{n=1}^{2^{64}} n$ times. This finite sum
|
||
|
|
is equal (<a href="https://de.wikipedia.org/wiki/Gau%C3%9Fsche_Summenformel">German Wikipedia</a>) to
|
||
|
|
$\frac{1}{2} 2^{64} {(2^{64} + 1)} = 1.7014 \cdot 10^{38}$. Quite a lot! Keep in mind that this
|
||
|
|
calculation does not factor in any other busses that the SoC might use; they can, probably, use their own
|
||
|
|
address space.</p>
|
||
|
|
<p>So, long story short: We need to tell the kernel about all the hardware beforehand. This is where the so-called
|
||
|
|
Device Tree comes into play. It is a structured way of describing the attached hardware. You can find examples
|
||
|
|
in the kernel tree under <code>arch/arm{,64}/boot/dts/</code>. The problem that arises for my phone is that it
|
||
|
|
uses the Exynos SoC from Samsung. While Exynos 7 or older would just require an addition to the already existing
|
||
|
|
Device Tree files, the <em>S7</em> uses the Exynos 8890 SoC. This one is not in mainline, which mean that it is
|
||
|
|
required to port it from the <a href="https://github.com/ivanmeler/android_kernel_samsung_universal8890/">downstream kernel</a> into mainline.</p>
|
||
|
|
<h3 id="device-support">Device Support</h3>
|
||
|
|
<p>The challenge that follows, provided I don't brick my phone, is the kernel support for the SoC's hardware.</p>
|
||
|
|
<h4 id="gpu">GPU</h4>
|
||
|
|
<p>The GPU of the Exynos 8890 SoC is a Mali-T880 from ARM. While there is no "official" FOSS-driver for it, one
|
||
|
|
is in development: <a href="https://gitlab.freedesktop.org/panfrost/linux">Panfrost</a>. One of the developers once
|
||
|
|
mentioned in PostmarketOS' Matrix channel that the driver is not ready for day-to-day use. But hopefully it
|
||
|
|
will be in the forseeable future.</p>
|
||
|
|
<h4 id="wifi">Wifi</h4>
|
||
|
|
<p>While I found no data on the Exynos 8890's Wifi-chip, I managed to allow the downstream kernel to use it, albeit
|
||
|
|
with its proprietary firmware (<a href="https://gitlab.com/postmarketOS/pmaports/merge_requests/309">MR</a>).</p>
|
||
|
|
<p>This patch requires a patch which changes the path of the firmware in the file <code>drivers/net/wireless/bcmdhd4359/dhd.h</code>.
|
||
|
|
The license header of <a href="https://github.com/ivanmeler/android_kernel_samsung_universal8890/blob/lineage-15.0/drivers/net/wireless/bcmdhd4359/dhd.h">said file</a>
|
||
|
|
hints at a chip from Broadcom. The model of the chip appears to be 4359. What the <em>dhd</em> stand for? I don't know.</p>
|
||
|
|
<p>Looking at the compatibility of the <a href="https://wireless.wiki.kernel.org/en/users/drivers/brcm80211">kernel modules</a> for Broadcom wireless chips, we can find
|
||
|
|
that the <em>BCM4359</em> chip is compatible. But is that the same as the module folder's name specifies? Again, I don't know.
|
||
|
|
Hopefully it is...</p>
|
||
|
|
<h4 id="other-components">Other Components</h4>
|
||
|
|
<p>At the time of writing this post, it has been a "long time" since I last flashed PostmarketOS on
|
||
|
|
my phone to look at what the kernel is saying. All of this device data I gathered by looking at
|
||
|
|
spec sheets by Samsung or the kernel. So I don't really know what other hardware is inside my
|
||
|
|
<em>S7</em>.</p>
|
||
|
|
<h2 id="next-steps">Next Steps</h2>
|
||
|
|
<p>The next steps are actually testing things out and playing around with values and settings and all kinds of things.</p>
|
||
|
|
<h2 id="other-devices-i-have-lying-around">Other Devices I Have Lying Around</h2>
|
||
|
|
<p>This may be off-topic for the "<em>Mainline Hero</em>" series but I recently tried to find out whether another device
|
||
|
|
I have lying around - a <em>Samsung Galaxy Note 8.0</em> - also uses such a MUIC to multiplex its USB port. While
|
||
|
|
at first I somehow found out, which I now know is wrong, that the <em>Note 8.0</em> uses the same <em>Maxim 77854</em> as my
|
||
|
|
<em>S7</em>, I discovered that the <em>Note 8.0</em> does use a MUIC, just not the <em>77854</em>. Since I found no other links
|
||
|
|
talking about this, I am not sure until I test it, but what I will do is tell you about how I reached this
|
||
|
|
conclusion!</p>
|
||
|
|
<p>If you <code>grep</code> the <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/arch/arm64/configs/exynos8890-herolte_defconfig">defconfig for the herolte</a> for
|
||
|
|
"<em>77854</em>", then one of the results is the flag <code>CONFIG_MUIC_UNIVERSAL_MAX77854</code>. The prefix <code>CONFIG_MUIC</code> makes
|
||
|
|
sense since this enables kernel support for the <em>Maxim 77854</em> <strong>MUIC</strong>. As such, we should be able to find
|
||
|
|
an enabled MUIC in the <em>Note 8.0</em>'s <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/blob/lineage-16.0/arch/arm/configs/lineageos_n5110_defconfig">defconfig</a>.</p>
|
||
|
|
<p>If we grep for <code>CONFIG_MUIC</code>, then we indeed get results. While the results do not look like the one for
|
||
|
|
the <em>77854</em>, we get ones like <code>CONFIG_MUIC_MAX77693_SUPPORT_OTG_AUDIO_DOCK</code>. This indicates that the <em>Note 8.0</em>
|
||
|
|
has a <em>Maxim 77693</em> MUIC built in. But it's not a very strong indicator. Since the <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/">kernel source</a> is available
|
||
|
|
on Github, we can just search the repo for the keyword "<em>MAX77693</em>". One of the results hints at the file
|
||
|
|
<code>drivers/misc/max77693-muic.c</code>. Looking at the Makefile of the <code>drivers/misc</code> directory, we find that this
|
||
|
|
source file is only compiled with the KConfig flag <code>CONFIG_MFD_MAX77693</code>. Grepping the <em>Note 8.0</em>'s defconfig
|
||
|
|
for this flag yields the result that this kernel module is enabled, hence hinting at the existence of a MUIC
|
||
|
|
in the <em>Note 8.0</em>.</p>
|
||
|
|
<p>If we take a closer look at the source file at <code>drivers/misc/max77693-muic.c</code>, we can find an interesting part
|
||
|
|
at <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/blob/b7ffe7f2aea2391737cdeac2a33217ee0ea4f2ba/drivers/misc/max77693-muic.c#L102">line 102</a>:</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||
|
|
</span><span> ADC_JIG_UART_ON = 0x1d, /* 0x11101 619K ohm */
|
||
|
|
</span><span>[...]
|
||
|
|
</span></code></pre>
|
||
|
|
<p>This means that, as the <em>Maxim 77854</em> requires a 619kOhm resistor to enable UART, we can debug
|
||
|
|
the <em>Note 8.0</em> with the same serial cable as the <em>S7</em>.</p>
|
||
|
|
<p>Plugging it into the DIY serial cable and booting it up, we also get some output:</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||
|
|
</span><span>BUCK1OUT(vdd_mif) = 0x05
|
||
|
|
</span><span>BUCK3DVS1(vdd_int) = 0x20
|
||
|
|
</span><span>cardtype: 0x00000007
|
||
|
|
</span><span>SB_MMC_HS_52MHZ_1_8V_3V_IO
|
||
|
|
</span><span>mmc->card_caps: 0x00000311
|
||
|
|
</span><span>mmc->host_caps: 0x00000311
|
||
|
|
</span><span>[mmc] capacity = 30777344
|
||
|
|
</span></code></pre>
|
||
|
|
<p>Theory proven! We <strong>can</strong> also serial debug the <em>Note 8.0</em> using the same cable.</p>
|
||
|
|
<h2 id="some-closing-words">Some Closing Words</h2>
|
||
|
|
<p>I want to emphasize that just very few of the things I mentioned were discovered or implemented by me. I just collected
|
||
|
|
all these information to tell you about what I learned. The only thing that I can truly say I discovered is the MR for
|
||
|
|
the Wifi firmware...</p>
|
||
|
|
<p>Additionally, I want to make it clear that I have no idea about microelectronics, electronics or ARM in general. All the
|
||
|
|
things I wrote that are about ARM or electronic - especially everything in the <em>Device Tree</em> section - is pure speculation
|
||
|
|
on my side. I never really looked into these things, but all the statements I made make sense to me. You can't just probe
|
||
|
|
$2^{64}$ different memory addresses just to figure out how much RAM you have, can you?</p>
|
||
|
|
|
||
|
|
</article>
|
||
|
|
|
||
|
|
<!-- Common post footer -->
|
||
|
|
<div class="mt-6">
|
||
|
|
<span class="prose lg:prose-lg text-md text-white">
|
||
|
|
If you have any questions or comments, then feel free to send me an email (Preferably with GPG encryption)
|
||
|
|
to papatutuwawa [at] polynom.me or reach out to me on the Fediverse at <a href="https://social.polynom.me/papatutuwawa">@papatutuwawa@social.polynom.me</a>.
|
||
|
|
</span>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|