AntoniAloyTorren has quit [Ping timeout: 272 seconds]
AntoniAloyTorren has joined #linux-exynos
cmeerw has joined #linux-exynos
cmeerw has quit [Ping timeout: 240 seconds]
psydroid has joined #linux-exynos
tobiasjakobi has joined #linux-exynos
tobiasjakobi has quit [Remote host closed the connection]
antoine62[m] has joined #linux-exynos
<krzk>
Grimler: Viciouss: The interrupt is active low, not edge falling. If seeing interrupt storm, it means interrupt somehow is pulled low (triggered). I think with the previous setup - edge falling - the interrupt simple hits once and never again. It's not working.
<krzk>
Unless I mistaken the pins (there are INTB and ALERT pins)...
<Grimler>
krzk: I can confirm that the interrupt still seem to happen, but just once, with edge falling
<krzk>
which could be... AF_PMIC_IRQ (the active low) is XEINT_13 (gpx1-5), not gpx2-3 as configured in DTS.... and FUEL_ALERT is XEINT_19 so gpx2-3... but this is also described as open-drain.
<krzk>
Grimler: Viciouss: other question - midas.dtsi configures fuel gauge as maxim,max17047 but exynos4412-p4note.dtsi different - maxim,max17042... a little bit weird, should be also checked.
<krzk>
Grimler: I don't have the device so someone would need to debug it more. The interrupt reports 0x400 in status which is STATUS_INTR_SOCMIN_BIT (and STATUS_SMN_BIT - the same). This means that current battery level (SoC) dropped below configured minimum and this triggers interrupt.
<krzk>
Grimler: since SoC is not valid, maybe the thresholds are wrong. The thresholds are configured in MAX17042_SALRT_Th and the code was writing there 0x3d3b.
<krzk>
Which I think is a threshold <59,61>... (0x3b, 0x3d) makes sense as the SoC is 60 and driver configures threshold on +/- 1% point.
<krzk>
Therefore the problem is - the driver configures SoC threshold based on wrong value of SoC (state of charge) and device triggers interrupt all the time, as alert/threshold is reached all the time
<krzk>
DT, so all current users might have this problem. The patch therefore - with good explanation - is a candidate for mainlining.
hexagonwin has joined #linux-exynos
<hexagonwin>
Hello, I was trying to mainline the Samsung Galaxy Note 4. The phone is "SM-N916S", Galaxy Note 4 S-LTE, codenamed as "tre3calte". It has an Exynos 5433 chip. The support for mainline was added for the Samsung Tizen reference device, Samsung TM2, and from what I have searched this device seems like a renamed version of the note 4. I tried renaming
<hexagonwin>
the tm2's device trees to fit my device, and booted, and I had postmarketOS installed on the phone. However, the screen was stuck on the samsung logo. And I tried again and had put a "crash" script on the initramfs, however the device didn't crash. It was hard for me to get more informations about if my Note 4's firmware supports 64bit mode, and
<hexagonwin>
what exactly is the TM2 device, and how to uart the phone, so I came here to ask about it. Sorry for leaving the long question right after coming in. Thanks.
<Grimler>
krzk: thanks for all the insights! I'll try to get more familiar with the max17042 code and investigate the interrupt issue further
<Grimler>
hexagonwin: uart should be possible with a "standard" micro-usb cable with 619 kOhm between ID and GND pin. I have successfully gotten uart on other exynos5433 devices that way
<hexagonwin>
Thanks!
<hexagonwin>
So I would need to tear the micro usb "data" cable, solder the 619 kOhm on those two pins, right?
<Grimler>
hexagonwin: usually not that simple, the micro-usb male that you find in normal cables usually only have 4 pins with the 5th ID pin omitted, so you need to buy a micro-usb male breakout board which has all 5 pins. I have one from SparkFun which works well ("USB MicroB Plug Breakout")
<krzk>
hexagonwin: Grimler: or get a PiMux :)
<hexagonwin>
PiMux..?
<krzk>
Although PabloPL had trouble with it on Galaxy S6.\
<krzk>
Grimler: I don't think the interrupt is a problem but the SoC level and setting the SoC threshold levels for the alert (triggering interrupt)
<Grimler>
> PabloPL had trouble with it on Galaxy S6
<Grimler>
Interesting, I has worked for me on S6 edge. Has worked on all micro-usb devices I have tried. At least bootloader messages, the android kernel does not always print anything unless CMDLINE is modified
<hexagonwin>
Thanks, if it's N910 it should probably be almost compatible with the N916. (I can install the Android OS for N910 on my phone)
<hexagonwin>
krzk Do you know where I can buy the MuxPi device? It seems like there are normal pins UART, can I get the UART of the n916 target working with this? Thanks.
<krzk>
hexagonwin: the UART pins usually were accessible if you open the device and have soldering toolkit. But the trick would be to find them :)
<krzk>
so recommended is to have UART on USB with MuxPi or Grimler's method
<hexagonwin>
I'm sorry for keep asking about (kind of) off topic things. Does the site also display "Sold out" for you or is it shown to me by detecting my country or something? Thanks.
<krzk>
yeah, sold out
<hexagonwin>
I guess I would have to stick with Grimler's methond unfortunately, I can't seem to find a page to buy the MuxPi device anywhere :(
<hexagonwin>
Or, is there a way to compile the linux-mainline kernel with the tm2 (note 4) dts and armv7 compiler? So that I can check if it's the issue of bootloader being 32bit-only or not. Thanks
<Grimler>
Doesn't the muxpi also require soldering to RX/TX pins on main board, or a special usb male with a resistance to put the MUIC on a typical (android) device in "uart-mode"? The muxpi provides an easy way to get the right uart voltage, but looks like the actual connection to the device needs to be soldered/created in any case
<hexagonwin>
Ah.. in that case it won't be a big difference for me than just buying the thing from SparkFun and soldering.
<krzk>
Grimler: then the MuxPi would be simple voltage converted so basically useless :)
<krzk>
hexagonwin: just don't burn the pins, they are 1.8V level. About the bootloader - that's correct, TM2 uses U-Boot but it does not answer whether special S-Boot or BL1/BL2 allowing chainloading is needed.
<hexagonwin>
Thanks. I'll try finding a USB TTL adapter that supports 1.8v switching.
<krzk>
hexagonwin: The stock Note4 was indeed armv7 but I don't remember whether this was limitation of S-Boot as well. The TM2 could boot also in 32-bit - I think early Tizen trees were doing it that way.
<hexagonwin>
Thanks. Would just copying the dts to arch/arm/boot/dts and compiling with armv7 cross compiler be enough? Or will any modifications be needed? Thanks.
hexagonwin has quit [Quit: Client closed]
hexagonwin has joined #linux-exynos
<hexagonwin>
I just realized that "Das U-Boot" 's source code is licensed as GPL, if then is it possible to legally request the source code for the fork of u-boot for samsung-tm2 to samsung? Thanks.
<Grimler>
hexagonwin: might be easier to start with a minimal dts (i.e. remove most things from the tm2 dts), and verify that you can get some logs or life-signs from the kernel, and then add more and more things
<hexagonwin>
With normal arm64 kernel? Thanks.
<Grimler>
I suspect you will have problems with arm64, without doing some magic through u-boot, but you can try, and if it does not work try a minimal arm version instead
<hexagonwin>
Thanks. I'll try making a 32bit version then..
hexagonwin has quit [Quit: Client closed]
chewitt_ has joined #linux-exynos
chewitt has quit [Ping timeout: 268 seconds]
PabloPL has joined #linux-exynos
<PabloPL>
Grimler: Hi. Did You used muxpi on S6 Edge device? Or You did talked about normal usb cable with soldered correct resistors to ID pin?
<PabloPL>
Grimler: Second one (with manually soldered cable) did worked for 7420 (s6)/8890 (s7)/7578 and s5pv210 (i9000), but i though that since i have muxpi maybe i can make use of it
cmeerw has joined #linux-exynos
PabloPL has quit []
<Grimler>
PabloPL: Hi, manually soldered/normal usb cable. I haven't had the opportunity to try the muxpi, do I understand it correctly that you anyways need a micro-usb male with the ID pin exposed to connect to the device?
<Grimler>
or rather, to get the MUIC to forward uart messages
<Viciouss>
krzk: the vendor kernel for the note 10.1 family of devices has the max17042 enabled in all defconfigs, I also found it in the s2 and tab2. other devices like the s3, the note ii and the note 8.0 have the max17047 configured
<Viciouss>
as the max17047 has a public datasheet, I contacted maxim about the 17042. they told me that it cannot be made public but they also told me that I should have a look at the max17047/50 one instead, so I guess it's basically identical, at least from a configuration pov
<Viciouss>
from what I remember the max17047 has a hand full of registers more related to the modelgauge algorithm, but the rest was identical
<Viciouss>
for the interrupts, if I'm not mistaken right now, it was triggered more than once but less frequently for me when it was still configured as edge falling.. but I could be wrong here, I'd need to check
chewitt_ is now known as chewitt
<Viciouss>
well after having a closer look, it seems that there might be some differences. the current mainline driver reads at least one register that is marked as reserved in the 17047 data sheet