ftg has quit [Read error: Connection reset by peer]
evgeny_boger has quit [Ping timeout: 480 seconds]
grming has quit [Quit: Konversation terminated!]
Net147_ has quit []
Net147 has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gamiee has quit [Remote host closed the connection]
gamiee has joined #linux-sunxi
gamiee has quit [Remote host closed the connection]
gamiee has joined #linux-sunxi
pabs has quit [Ping timeout: 480 seconds]
qwestion has joined #linux-sunxi
pabs has joined #linux-sunxi
qwestion has quit [Remote host closed the connection]
Daanct12 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
Daanct12 has quit [Quit: Leaving]
cnxsoft has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft1 has quit []
vagrantc has quit [Quit: leaving]
diego71 has quit [Server closed connection]
diego71 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<smaeul>
dikiy: When charging, the voltage supplied to the battery has to be above the battery's internal voltage. From the AXP803 datasheet, I_END = 0.1 * I_CHRG, where I_CHRG == constant_charge_current in sysfs.
<smaeul>
So just before the battery stops charging, the actual voltage will be something like V_TRGT + (I_END * RDC) [Ohm's law]. RDC is the battery's internal resistance, reported in registers 0xBA and 0xBB.
<smaeul>
This is the same reason the measured voltage is below the battery's internal voltage (aka open-circuit voltage or OCV) when discharging
<smaeul>
you can override strict devmem at boot with the parameter iomem=relaxed
<smaeul>
but the regmap debugfs interface is way nicer to use, even if you have to recompile your kernel to set REGMAP_ALLOW_WRITE_DEBUGFS
<smaeul>
apritzel: no, there is nothing special I know of. PLLs are just like H616 and newer (with separate output gates). the only time I touch a PLL in U-Boot is to bump up the CPU speed
<smaeul>
(I have a working T113 U-Boot locally)
ndufresne has quit [Server closed connection]
ndufresne has joined #linux-sunxi
ndufresne is now known as Guest768
oliv3r[m] has quit [Server closed connection]
oliv3r[m] has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
t4h4[m] has quit [Server closed connection]
t4h4[m] has joined #linux-sunxi
dikiy has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
dikiy has quit [Quit: leaving]
Hypfer has quit [Server closed connection]
Hypfer has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
smaeul: I got it working yesterday as well, although chickening out with the SPL part by hacking awboot to return to FEL ;-)
<apritzel>
smaeul: I have a clean solution for pinctrl, even with our legacy pinctrl driver in the SPL
<smaeul>
I have SPL working, but it's more hacks on top of the D1 hacks :)
<apritzel>
smaeul: and it boots, but MMC is not working
<apritzel>
works in Linux, though
<apritzel>
(I meant MMC is not working in U-Boot, it probes, but doesn't do anything, sees no card, etc)
<smaeul>
are you booting Linux in secure or NS?
<smaeul>
I can boot Linux fine in secure mode, but of course that means no PSCI. in NS mode I get complaints from the GIC driver
<apritzel>
yeah, I disabled PSCI for now, so I guess it's still secure
<smaeul>
MMC driver works fine for me. I'm not using FEL at all
<apritzel>
I mainly wanted to prove my pinctrl changes
<smaeul>
yeah, it will be great to get some mergeable solution for that
<apritzel>
I will try to post it over the weekend
<apritzel>
re GIC> interesting, I will have a look. Secure GIC init should be handled by U-Boot, in the PSCI code
<smaeul>
I'm hitting the `pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");` in Linux
ad__ has quit [Server closed connection]
ad__ has joined #linux-sunxi
<apritzel>
smaeul: looks like AW messed up the CBAR register, by copy&pasting the wrong address
<apritzel>
it's supposed to contain the base address for the GIC registers, but it reads 0x1c80000
<apritzel>
the author of nonsec_virt.S naively assumed that CBAR can be used to avoid platform specific variables ;-)
<apritzel>
but AW is not the first one to mess this up, so there is an override. Just need to move that into Kconfig and set the correct value
sunshavi has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
mripard has quit [Server closed connection]
mripard has joined #linux-sunxi
rajkosto has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
libv: mnemoc: is that "people at work" or is the (main) Wiki down again? minima seems to be still up ...
KBedrockLinuxLoongarchPortMain has joined #linux-sunxi
warpme____ has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
<LordKalma>
havin moderate success in reverse engineering the U-Boot for the X6100
Danct12 has quit [Remote host closed the connection]
evgeny_boger1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
<apritzel>
no, the board/ directory is not used for sunxi, except for common sunxi code
<apritzel>
LordKalma: do you have a driver for that panel in U-Boot?
<apritzel>
enablement should go in there, at the minimum
<apritzel>
but actually you should describe that in the DT, so that it is handled more or less automatically
<apritzel>
in any case it won't be sufficient to copy the ill-fated BSP idea of relying on U-Boot to initialise the panel
<apritzel>
my hunch is that there is just one or two regulators that need to be enabled, which we typically model with "xxx-supply" properties in the DT
<LordKalma>
apritzel, we don't mind at all loosing the ability to put a logo on the bootloader hahah
<LordKalma>
"there is just one or two regulators that need to be enabled, which we typically model with "xxx-supply" properties in the DT"
<LordKalma>
do you have an example of that?
<LordKalma>
in fact, we're thinking of maybe just putting that initialization code on the kernel driver
<LordKalma>
and forget the u-boot driver
<LordKalma>
it seems simple enough, assuming linux has an easy way to do spi haha
milek7 has quit [Server closed connection]
milek7 has joined #linux-sunxi
<apritzel>
LordKalma: please don't hack this. If you just put a regulator in the DT, then it works nicely in both Linux and U-Boot
xypron has quit [Server closed connection]
xypron has joined #linux-sunxi
<apritzel>
LordKalma: do you use an existing kernel driver?
Esmil has quit [Server closed connection]
Esmil has joined #linux-sunxi
<LordKalma>
But I think it's not just a regulator, looking at that code from the uboot decompilation... it seems to do a series of writes
<LordKalma>
maybe some init routine
<LordKalma>
apritzel, no, the driver was reverse engineered from their linux kernel. It was that one I kept complaining and despairing why it didn't work, and then we discovered that it works when you use stock u-boot
<LordKalma>
and that's why we're looking at u-boot to figure out how and why
<apritzel>
the question is what the enable sequence does: if it's programming screen dependent parameters into the controller, that should be factored out
<LordKalma>
that's a very relevant question. I didn't send the data for the ST7701 by accident.
<LordKalma>
This panel uses the ST7701*S* controller
<LordKalma>
but the panel itself is a Jinglitai JLT4013A
<LordKalma>
I made the driver for the *panel* specifically
<LordKalma>
dindn't make any controller specific things
<LordKalma>
the target should be more akin to this
<jernej>
LordKalma: if you have logic analyzer, capturing SPI communication would probably be the easiest way. At least to get some idea what's going on.
<LordKalma>
I have one in the mail yap
<LordKalma>
what an adventure I decided to go on
<LordKalma>
I honestly did not expect this rabbit hole
upnix has quit [Quit: Page closed]
<LordKalma>
Fortunately now we're two working on this :)