ftg has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
Guest1883 has quit [Server closed connection]
immibis_ has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
jemk has quit [Server closed connection]
jemk has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
miasma has quit [Server closed connection]
miasma has joined #linux-sunxi
karlp has quit [Server closed connection]
karlp has joined #linux-sunxi
blathijs has quit [Server closed connection]
blathijs has joined #linux-sunxi
arti has quit [Server closed connection]
arti has joined #linux-sunxi
hallyn has quit [Server closed connection]
hallyn has joined #linux-sunxi
ats has quit [Server closed connection]
cnxsoft has quit [Read error: Connection reset by peer]
ats has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
rtp has quit [Server closed connection]
rtp has joined #linux-sunxi
libv has quit [Server closed connection]
libv has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
mehdix has quit []
mehdix has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
pabs has quit [Ping timeout: 480 seconds]
pabs has joined #linux-sunxi
LordKalma has quit [Server closed connection]
LordKalma has joined #linux-sunxi
Daanct12 has quit [Quit: Quitting]
aerospace[m] has quit [Server closed connection]
aerospace[m] has joined #linux-sunxi
pabs has quit [Read error: No route to host]
pabs has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
z3ntu has quit [Server closed connection]
z3ntu has joined #linux-sunxi
dikiy has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
dikiy has joined #linux-sunxi
<dikiy>
Hey all! Some question: I've set the voltage_max_design for the battery to 4.35V (on Pinephone) and put it charging. But when the charge was on ~99% I saw the voltage_now is equal to 4.4V. Is it a bug? Or voltage_max_design cuts-off the charging on different way?
pmp-p is now known as Guest669
pmp-p has joined #linux-sunxi
Guest669 has quit [Ping timeout: 480 seconds]
pmp-p has quit []
pmp-p has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Quit: evgeny_boger]
<gnarface>
if dikiy comes back tell them to ask that question in #pinephone on irc.pine64.org
dikiy has joined #linux-sunxi
<dikiy>
gnarface: Ah, I asked here, because if its issue, then its a kernel one.
<dikiy>
and sunxi is very close to A64 system with AXP803 power controller there
<gnarface>
yea but i know people that hang out in #pinephone actually have the answer i just don't remember it
<gnarface>
i think most the other A64 implementations in the wild these days are not battery powered
<gnarface>
all i vaguely remember was that there's like 3 settings you can put it at and something about a suspicion that the pine64 batteries are a little weaker than reported but closer to the hardware's expected behavior than the 3rd party ones
<dikiy>
BTW, I try to hack into the registers of AXP803, but still no idea how to do it from userspace
<dikiy>
sure, this is not a question of this particalar sace, but I'm failing to find the proper documentation
<dikiy>
Ans kernel sources are so big...
<dikiy>
so, my question would be, if its possible to access the HW registers from the userspace? For example, the registers from Serial Port a mapped into the userspace, but what about registers of other hardware?
<karlp>
I mean, if it's connected via i2c, you should be able to jsut use i2ctools like normal?
<karlp>
not sure what userspace handles RSB though.
<dikiy>
As I see SCK and SDA are connected. Its I2C, no?
grming has joined #linux-sunxi
<apritzel>
dikiy: it's both, actually. The AXP speaks both protocols, and those pins are muxed to both the RSB and an I2C controller
<karlp>
should be able to see it in the device tree as well.
<apritzel>
but we initialise the RSB to speak RSB
<apritzel>
but we initialise the AXP to speak RSB
<karlp>
what advantages does that give? (other than preventing inadventert users talking to their own pmic by accident ;)
<apritzel>
you can talk to the RSB controller via /dev/mem, the register sequence to send an RSB command is simpler than via (the Allwinner implementation of) I2C
<karlp>
is sunxi i2c problematic historically?
<apritzel>
for a start, AW claims that some AXP chips behave less reliable via I2C
<karlp>
that's enough of ans wer for me :)
<karlp>
i2c's always a shitshow, but at least it's a common shitshow
<apritzel>
though I still have to see proof or some actual rationale for that
<apritzel>
also RSB is much faster (3MHz) than I2C (100KHz), so you can send commands more quickly
<dikiy>
apritzel: And how can I talk to AXP803 through /dev/mem?
<apritzel>
karlp: I am a bit doubtful this performance argument matters, though
<apritzel>
karlp: also RSB is much more fire-and-forget, so it's simpler to just program a command into the controller, and then it does the rest automatically
<dikiy>
karlp: yes, but I didnt give an importnce, as I though "who the hell would use RSB if there is a cooomon I2c available" xD
<apritzel>
I2C requires much more hand holding
<apritzel>
at least the Allwinner implementation of it
<apritzel>
dikiy: can't you dump some AXP state from sysfs?
JohnDoe_71Rus has quit []
<dikiy>
in sysfs are only capacity, voltages, etc
<dikiy>
And I wanted to see if I can reprogram OCV-State of charge table
<apritzel>
so that sequence I showed above seems to work for me
<apritzel>
but you have to turn off the ondemand governor, if you use that, otherwise you will interfere with the kernel driver, and get somewhat random values from the data register
<apritzel>
mmh, weird, I can't seem to write to the RSB register, though reading works
dikiy has quit [Ping timeout: 480 seconds]
<karlp>
weird. devmem2 really is still busted. packaged up in ubuntu and friends, never actually changed or fixed, still the same 2000 version.
<apritzel>
dikiy: and yes, CONFIG_IO_STRICT_DEVMEM needs to be off, the kernel config help text explicitly mentions our case here (poking behind a driver's back)
<karlp>
busybox "devmem" has had 64bit properly since at leat 2008, I don't feel like tracking the git log across the next set of file renames.
<karlp>
that's so odd.
<apritzel>
karlp: I tried fixing this back then, but could find a canonical source
<karlp>
(it even got 128bit support this year)
<karlp>
apritzel: yeah, I dont' see any good "upstream" either.
<apritzel>
and somewhat lost interest, since it had more shortcomings and issues, and I wanted more, so I did the wrong thing and started my own tool ;-)
<karlp>
yeah,
<karlp>
I'm on openwrt normalyl, so ive'g to the busybox version anyway, and it "just works"
<apritzel>
for busybox it's fine, devmem2's simple, basic functionality fits nicely into busybox
<apritzel>
yeah, I remember that ...
<karlp>
no, I mean, busybox has it's own "devmem" which has been maintained and fixed.
<karlp>
I wonder what "devmem2" was meant to replace, or what the mythical devmem originally was.
<karlp>
but yeah, too much time dissappearing in this rabbit hole already
<apritzel>
right, what was I about to do? ;-)
<apritzel>
ah right, interesting discovery: if the SPL is bigger than 32KB, older SoCs ignore that, and keep searching for more eGONs
<karlp>
man debian rejected devmem2 in 2010, said that work should be done on getting busyboxes version, yet ubuntu snuck it in, to use as a tool for identifing some versions of power vr chipsets for beaglebone.
<karlp>
and it's hung there, unchanged ever since.
<karlp>
devmem2 being "too broken, not portable"
<apritzel>
that was my impression as well
<apritzel>
regarding 32K SPLs: that allows to put U-Boot versions for two different boards on one SD card, if one is H6 or later, and the other is not
<apritzel>
the >=H6 SPL needs to be bigger than 32K, and is put at 8K, the other SPL goes to 128K
<apritzel>
and both SPLs need to have their U-Boot FIT image offset adjusted at build time
<apritzel>
libv: mnemoc: did the search change for the new Wiki?
<apritzel>
when I for instance search for Mangopi, the old Wiki gives me a proper result list, whereas the new one just comes back empty, short of some suggestions in the search box
<apritzel>
libv: mnemoc: and thanks for doing this, btw. I edited two articles the other day, in the new Wiki, and didn't spot any issues with that, including preview, view changes, and the good ol' ModelT question when adding links ;-)
<dikiy>
apritzel: I recompiled the kernel and disabled STRICT_DEVMEM, but still get operation not permitted
hallyn has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft1 has quit []
upnix has joined #linux-sunxi
dikiy has quit [Ping timeout: 480 seconds]
dikiy has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<dikiy>
wow guys. I'm pretty lost in this conversations. What sould I try tough?
<dikiy>
busybox, devmem2?
<dikiy>
I dont even know this words xD (despite of busybox)
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
ftg has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<upnix>
I have a device that boots from TOC0 images - can someone confirm for me that this is the reason why modifying my Android boot.img causes the device to fail to boot?
<upnix>
When I modify the boot.img, I see the console output: FAT: Misaligned buffer address (bbe7e678), and, "image_len not match, actual:19466240, expected:19234816" - neither of which I get with the vendor boot.img
<apritzel>
upnix: be warned that tinkering with some vendor image is a giant valley of tears and pain, plus a waste of time
<apritzel>
and I don't think that has anything to do with TOC0 or secure boot
<apritzel>
it just looks like there is some code in there that expects a certain length?
<upnix>
apritzel: Fair enough. Just now I got the RX pin working on my serial console, and I was able to interrupt the boot. Does this mean I might be able to create a bootable system image?
dikiy has quit [Ping timeout: 480 seconds]
<apritzel>
with some vendor bits?
<jernej>
apritzel, dikiy: Is this mainline kernel? If so, then there is regmap entry in debugfs which can be used to inspect register values or even set it.
<jernej>
If it is BSP kernel, then there is surely some debugfs interface to access PMIC devices, no need for devmem
<jernej>
(been there, done that))
<libv>
apritzel: the search thing i noticed too
<libv>
and thanks for the feedback
<libv>
so good, 2 open issues, the template File resolution when images/ has been renamed, and the search being weird
<apritzel>
upnix: what do you mean with "bootable system image"? Something mainline based?
dikiy has joined #linux-sunxi
<upnix>
apritzel: I might not be sure what I mean. I'm trying to figure out what I'm going to be able to do now. I've been able to boot into some Android recovery mode... Ultimatley, I'm still trying to load my own kernel modules, whether that be inside the Android 10 image, or own a mainline-based distribution.
<upnix>
Am I still a lot further away from that than I think?
<dikiy>
jernej: it is a 6.1 kernel from mobian
<dikiy>
~mainline :)
dikiy has quit [Ping timeout: 480 seconds]
dittid[m] has quit [Server closed connection]
dittid[m] has joined #linux-sunxi
w0ll3q1uszxabiwo7vet7op4fhjk84 has quit [Server closed connection]
w0ll3q1uszxabiwo7vet7op4fhjk84 has joined #linux-sunxi
<apritzel>
upnix: at the moment there is this DRAM setup problem. Once this is solved, you can run any mainline based bits
<apritzel>
for a pure mainline kernel, you will get eMMC, SD card, USB (with v6.2), but no Ethernet (WIP) or HDMI
<apritzel>
I believe Armbian has both working, so that would be an alternative
JohnDoe_71Rus has quit []
<apritzel>
smaeul: is there anything special in the base clock/PLL setup for the D1/T113s?
<apritzel>
smaeul: I saw that PLL_PERIPH0 is a bit different, are there any magic bits that need to be set?
vagrantc has quit [Quit: leaving]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
upnix: creating a Wiki account is a good first step ;-)